Re: Set COLLATE on a session level

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dirk Mika <Dirk(dot)Mika(at)mikatiming(dot)de>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Set COLLATE on a session level
Date: 2020-12-06 05:15:43
Message-ID: 03ede77a49f4e8085d885e0dc1c66128ebed8e27.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 2020-12-05 at 13:12 +0100, Peter Eisentraut wrote:
> On 2020-12-04 17:18, Tom Lane wrote:
> > > There is a SET COLLATION command in the SQL standard that does this.
> > > Someone just has to implement it. It wouldn't be terribly difficult, I
> > > think.
> >
> > [ squint... ] Just because it's in the standard doesn't mean it's a
> > good idea. It sounds like this is morally equivalent to a GUC that
> > changes query semantics. We have learned painfully that such behaviors
> > are best avoided, because they break things you didn't expect to break.
>
> I think it would be analogous to the schema search path.

Usually you notice right away if the "search_path" is wrong, because
relations won't be found.

But with a bad collation set in a session, the problems would be more
subtle. For example, if someone asks you why an index isn't used to
support sorting, you'd always have to remember to ask what collation
has been set in the session.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message 孙冰 2020-12-06 07:14:07 The hidden cost of limit-offset
Previous Message David G. Johnston 2020-12-05 20:00:49 Re: Using a boolean column with IF / THEN