Re: Final result (display) collation? - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Final result (display) collation?
Date
Msg-id 7aa0ee4fce2a99231b2eeeb8bb1a9feef3a71db2.camel@cybertec.at
Whole thread Raw
In response to Re: Final result (display) collation?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Final result (display) collation?
List 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 by date:

Previous
From: John Naylor
Date:
Subject: Re: Fix crash when non-creator being an iteration on shared radix tree
Next
From: Peter Eisentraut
Date:
Subject: Re: Regression tests fail on OpenBSD due to low semmns value