Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tor, 2011-03-10 at 17:16 -0500, Tom Lane wrote:
>> On the other hand ... one thing that's been bothering me is that
>> select_common_collation assumes that "explicit" collation derivation
>> doesn't bubble up in the tree, ie a COLLATE is only a forcing function
>> for the immediate parent expression node. It's not at all clear to me
>> that that's a correct reading of the spec. If it's not, the only way
>> we could make it work correctly in the current design is to keep
>> *two* additional fields, both the collation OID and an
>> explicit/implicit
>> derivation flag. Which would be well past the level of annoying.

> That's correct. I didn't finish implementing that yet because I didn't
> have a good solution for the annoyance bit. The patch I proposed early
> on that would have grouped type+typmod+collation into a separate Node
> would have provided a simple solution but did not go through. My
> assumption was that this issue was not critical to the core feature and
> could be solved later.

Adding a separate Node for those fields would hardly meet the core
objection, which is the extra space needed for the storage --- in fact,
it would make that problem considerably worse. But what did you think
of the idea of setting collations during a post-pass, so that the
collation derivation values need only be local storage during that
one recursive routine?

regards, tom lane