Re: Set COLLATE on a session level

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
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-04 16:18:39
Message-ID: 2156565.1607098719@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 2020-11-20 08:13, Dirk Mika wrote:
>> I know that I can specify a COLLATE for a SELECT statement in the ORDER BY Clause, but then I would have to adjust the statements in the client and statements that are automatically generated by the database components used, would not be affected.

> 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 also wonder just exactly what such a setting would do, and how it
interacts with the existing rules for deriving collations within a
query. Does parse_collate.c go out the window the minute somebody
sets a non-empty collation setting?)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Lewis 2020-12-04 16:22:19 Re: Alter the column data type of the large data volume table.
Previous Message Adrian Klaver 2020-12-04 16:17:48 Re: Accessing Postgres Server and database from other Machine