Re: Final result (display) collation?
От | Laurenz Albe |
---|---|
Тема | Re: Final result (display) collation? |
Дата | |
Msg-id | 7aa0ee4fce2a99231b2eeeb8bb1a9feef3a71db2.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Final result (display) collation? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Final result (display) collation?
|
Список | pgsql-hackers |
On Tue, 2024-12-17 at 20:36 -0500, Tom Lane wrote: > Jeff Davis <pgsql@j-davis.com> writes: > > Crazy idea: what if we treated the top-level ORDER BY as special? That > > is, we create a new node ResultOrderBy and make it visible in EXPLAIN. > > Then we can have a GUC to control the default collation only for that > > node. > > This seems like an amazing kluge, and it's not even clear that > there's any field demand for it. Yes, that approach seems strange. Also, wouldn't that prevent plans that calculate the final sort using a nested loop or merge join further down? But I like the idea of a parameter that determines the collation. I am aware that it is anathema here to have a GUC that influences query semantics, but it wouldn't be any worse than creating a database with a different collation, so I think it would be fine. FWIW, Oracle has a parameter NLS_SORT that does just that. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: