From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Rejecting redundant options in Create Collation |
Date: | 2020-10-01 18:46:53 |
Message-ID: | 540d49c2-2ed8-4dc2-a50e-4451eba24360@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Currently, it's not an error for CREATE COLLATION to be invoked
with options repeated several times. The last (rightmost) value is kept
and the others are lost.
For instance CREATE COLLATION x (lc_ctype='en_US.UTF8',
lc_collate='en_US.UTF8', lc_ctype='C')
silently ignores lc_ctype='en_US.UTF8'. But that kind of invocation
isn't likely to be legit. It's more plausible that it's the result of
some mistake or confusion.
The same goes for the other options:
CREATE COLLATION [ IF NOT EXISTS ] name (
[ LOCALE = locale, ]
[ LC_COLLATE = lc_collate, ]
[ LC_CTYPE = lc_ctype, ]
[ PROVIDER = provider, ]
[ DETERMINISTIC = boolean, ]
[ VERSION = version ]
)
I suggest the attached simple patch to raise an error when any of
these options is specified multiple times.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
Attachment | Content-Type | Size |
---|---|---|
create-collation-redundant-options.patch | text/plain | 724 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-10-01 18:58:53 | Re: Rejecting redundant options in Create Collation |
Previous Message | Tomas Vondra | 2020-10-01 18:41:33 | Re: WIP: BRIN multi-range indexes |