From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Rejecting redundant options in Create Collation |
Date: | 2020-10-02 14:37:03 |
Message-ID: | c479cfe0-f2ef-4cbf-b09b-d785473d58ca@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier wrote:
> > Hmm ... I think that that is pretty standard behavior for a lot of
> > our utility commands. Trying something at random,
>
> The behavior handling is a bit inconsistent. For example EXPLAIN and
> VACUUM don't do that, because their parenthesized grammar got
> introduced after the flavor that handles options as separate items in
> the query, so redundant options was not something possible with only
> the original grammar.
Assuming we agree that redundant options should consistently
raise an error for a certain class of statements, could it be handled
at the grammar level?
If "list of options enforcing uniqueness" was a grammatical construct,
the redundancy would be caught by the parser and there would be no
need for ad-hoc code in the implementation of utility statements.
I don't know if that makes sense, unfortunately I know next to nothing
about bison.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2020-10-02 14:53:17 | Re: enable_incremental_sort changes query behavior |
Previous Message | David G. Johnston | 2020-10-02 14:32:56 | a misbehavior of partition row movement (?) |