Re: Final result (display) collation?

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

In response to

Responses

Browse pgsql-hackers by date

  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.