Re: why can't plpgsql return a row-expression?

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