Re: Collations versus user-defined functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Collations versus user-defined functions
Дата
Msg-id 27925.1300036596@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Collations versus user-defined functions  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Collations versus user-defined functions  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Collations versus user-defined functions  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote:
>> I remain unconvinced, because there are too many corner cases.  Should
>> collation propagate up out of a subselect?  How about a CTE?  You're
>> starting to get into some pretty weird action-at-a-distance situations
>> if so, analogous to the function-input-arguments case that you were just
>> saying should NOT propagate collation.  And I still don't see anything
>> in the text of the spec to justify it.

> I said don't propegate the collation *state*, the collation should be
> propegated.

Well, it's exactly that distinction that's bugging me.  It seems a bit
arbitrary if collation propagates in certain cases where collation state
doesn't.  I'm concerned in particular that we're going to find ourselves
backend into a corner if someone comes up with a different reading of
the spec.  The proposed implementation will be incapable of propagating
collation state across subselect boundaries (because the post-parse scan
is going to operate at most one subquery at a time), so if someone
convinces us that we should do that, what then?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Collations versus user-defined functions
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Collations versus user-defined functions