Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 6, 2012 at 12:31 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> but we can limit a implicit coercion in tupconvert via new parameter -
>> because we would to forward plpgsql behave just from this direction.
>> Then when this parameter - maybe "allowIOCoercion" will be false, then
>> tupconvert will have same behave like before.
> It would be nice to make that work, but it could be left for a
> separate patch, I suppose. I'm OK with Tom's proposal to go ahead and
> commit the core mechanic first, if doing more than that is
> controversial.
I'm against putting I/O coercion semantics into tupconvert, period. Ever.
If plpgsql wants that behavior rather than something more consistent
with the rest of the system, it needs to implement it for itself.
If the per-column conversions were cast-based, it wouldn't be such a
flagrantly bad idea to implement it in tupconvert. I'm still not
convinced that that's the best place for it though. tupconvert is about
rearranging columns, not about changing their contents.
It might be more appropriate to invent an expression evaluation
structure that could handle such nontrivial composite-type coercions.
I'm imagining that somehow we disassemble a composite value (produced by
some initial expression node), pass its fields through coercion nodes as
required, and then reassemble them in a toplevel RowExpr.
regards, tom lane