| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com>, Kyle Spearrin <kspearrin(at)bitwarden(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | Justin Baur <jbaur(at)bitwarden(dot)com>, Vince Grassia <vgrassia(at)bitwarden(dot)com> |
| Subject: | Re: CREATE COLLATION without LOCALE throws error in v15 |
| Date: | 2022-12-08 18:29:31 |
| Message-ID: | 38ab220b-83a7-17a4-42b1-923a5f96ef15@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 07.12.22 18:44, Jeff Davis wrote:
> On Wed, 2022-12-07 at 13:04 +0100, Peter Eisentraut wrote:
>> This was an intentional change because of underlying conceptual and
>> catalog changes. lc_collate, lc_ctype, and iculocale are now tracked
>> separately in the catalogs. This is also important because for a
>> database they actually are used separately. So this also keeps the
>> locale/collation settings for databases and collations consistent.
>
> That makes sense, but there also doesn't seem to be much harm in
> supporting the old behavior where it works as long as ctype==collate.
> As in my patch, it accepts either locale or ctype==collate as the icu
> locale.
The harm is that in the context of database-level collations, the
analogous syntax means something different. That's why in the context
of adding ICU support on the database level, this syntax for collation
objects was disabled.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2022-12-08 19:59:42 | Re: CREATE COLLATION without LOCALE throws error in v15 |
| Previous Message | hubert depesz lubaczewski | 2022-12-08 11:13:13 | Re: WAL segments removed from primary despite the fact that logical replication slot needs it. |