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
