Re: tighten generic_option_name, or store more carefully in catalog?

Chapman Flack <jcflack(at)acm(dot)org> writes:
> generic_option_name is a ColLabel, therefore a fully general SQL identifier.

> But a command like CREATE FOREIGN DATA WRAPPER w ... OPTIONS ("a=b" 'c=d')
> stores {a=b=c=d} in fdwoptions, from which the original intent can't be
> recovered.

Ugh.

> Should generic_option_name be restricted to be a regular identifier,
> or allowed to be a delimited identifier but with = forbidden within it,
> or should it be represented as delimited in the catalog when necessary
> so it can be recovered faithfully?

I think I'd vote for leaving the grammar alone and rejecting '='
in the option-storing code. If memory serves, there's precedent
for that approach somewhere else in our code.

> SQL rules would also make its case-sensitivity dependent on faithfully
> recovering whether it was delimited or not.

I'm not following that part?

regards, tom lane