Re: Rejecting redundant options in Create Collation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: "Michael Paquier" <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Rejecting redundant options in Create Collation
Date: 2020-10-02 16:07:58
Message-ID: 1221644.1601654878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> 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?

I don't think this'd be a great idea. The grammar would have to
do something pretty brute-force to check for duplication, whereas
the individual statements typically know already whether they've
seen an instance of a particular option.

It will be kind of annoying to make similar changes in every statement,
agreed. I wonder if there'd be any value in trying to make a subroutine
that deconstructs a DefElem list according to a provided list of option
names, allowing centralized handling of unknown-option and
duplicate-option cases, and maybe sharing handling of the simpler cases
such as boolean and integer options. I'm not quite sure what the output
ought to look like though. Some sort of statement-specific struct would
be really ideal, but C doesn't make that easy.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-10-02 17:07:04 Re: Dumping/restoring fails on inherited generated column
Previous Message Heikki Linnakangas 2020-10-02 15:34:26 Re: Error code missing for "wrong length of inner sequence" error