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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty
Дата
Msg-id 1300219281.7581.19.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Collations versus user-defined functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty