Hi, Thanks for the review. Please see the updated patch.
Hmm. We're running an I/O cast during do_tup_convert() now, and look > up the required functions for each tuple. I think if we're going to > support this operation at that level, we need to look up the necessary > functions at convert_tuples_by_foo level, and then apply unconditionally > if they've been set up. > Done. TupleConversionMap struct should keep the array of functions oid's that needs to be applied. Though only for those cases where both attribute type id's do not match. This way no unnecessary casting will happen. > Also, what are the implicancies for existing users of tupconvert? Do we > want to apply casting during ANALYZE for example? AFAICS the patch > shouldn't break any case that works today, but I don't see that there > has been any analysis of this. > I believe this part of the code should not impact existing users of tupconvert. As this part of code is relaxing a restriction upon which an error would have been generated. Though it could have a little impact on performance but should be only for cases where attribute type id's are different and are implicitly cast able. Besides existing users involve tupconvert in case of inheritance. And in that case an exact match is expected. Regards, --Asif
return_rowtype.v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
