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

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.