Re: Rejecting redundant options in Create Collation

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

In response to

Responses

Browse pgsql-hackers by date

  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 (?)