| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Final result (display) collation? |
| Date: | 2024-12-18 07:26:31 |
| Message-ID: | 7aa0ee4fce2a99231b2eeeb8bb1a9feef3a71db2.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2024-12-17 at 20:36 -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-12-18 07:39:25 | Re: Regression tests fail on OpenBSD due to low semmns value |
| Previous Message | vignesh C | 2024-12-18 07:21:24 | Re: Added schema level support for publication. |