Re: tighten generic_option_name, or store more carefully in catalog? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tighten generic_option_name, or store more carefully in catalog?
Date
Msg-id 3020890.1748735715@sss.pgh.pa.us
Whole thread Raw
In response to tighten generic_option_name, or store more carefully in catalog?  (Chapman Flack <jcflack@acm.org>)
List pgsql-hackers
Chapman Flack <jcflack@acm.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



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Missing pg_depend entries for constraints created by extensions (deptype 'e')
Next
From: Nikolay Samokhvalov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements