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

On Thu, Mar 10, 2011 at 05:16:52PM -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.
> But in a post-pass implementation it would be no great trouble to do
> either one, and we'd not be looking at a forced initdb to change our
> minds either.

I beleive the current interpretation, that is the COLLATE only applies
to levels above, is the correct interpretation. COLLATE binds tightly,
so

A op B COLLATE C parses as A op (B COLLATE C)

which is why it works. It's actually the only way that makes sense,
otherwise it becomes completely impossible to specify different
collations for a function and its return value.

For example in your example with a view:

CREATE VIEW foo AS func(x COLLATE A) COLLATE B;

B is the collation for the output column, A is the collation for the
function.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle