Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty
Date
Msg-id 1300219281.7581.19.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Collations versus user-defined functions
Next
From: Tom Lane
Date:
Subject: Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty