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: | Raw Message | Whole Thread | 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. |