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
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 |