[ https://issues.jboss.org/browse/TEIID-1977?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-1977: -------------------------------- Fix Version/s: 8.1 (was: 8.0) Since the scope of updating to new driver may be more this this immediate JIRA, lets push this 8.1 release -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1977?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-1977. ----------------------------------- Resolution: Done There were several issues addressed by this fix: 1. the client encoding string value is needed, since the client checks for it by name. This means that the inverse mapping with duplicate mappings will result in an error. Also the client encoding was being handled in both the front end and the back end and the front end was never updated in the event of a encoding change. 2. the get_expr function is being used to check autoincrement. We had already added a specific check for a prepared case, but it made more sense to more fully implement the attrdef table and add a dummy implementation of the get_expr function (also logged TEIID-2031). 3. there were several new columns needed on the pg catalog, such as the delim, attrnotnull, etc. this changes quite a few expected results as the uuids are now off. 4. portal executions were always sending the row description. This is against protocol. With the new JDBC driver that causes an ArrayIndexOutOfBounds. Ensuring that we can always get metadata for preparedstatements (a refinement of TEIID-2023) ensures that we always properly respond to the describe portal request. 5. precision and scale values were not optimally reported since the row description mod value was hard coded to -1. Changing to the calculated value on the attribute table means that string precisions/lengths are now metadata driven - although this may be dangerous if the length is used as a buffer length and the length is exceeded. However without this change the old client would report a value of 0 and the new client would use max int - neither of which are very good values either. I manually made sure that the logic was still compatible with the 8 series pg jdbc driver, but we could consider adding another module with the 8 dependency to ensure that we don't have regressions. We also need to validate the latest true ODBC driver to see if there are any issues. As for back-porting. Should anyone change client encoding after init time, then #1 could be needed on older branches. #5 may also be desirable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira