From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <jcflack@acm.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: tighten generic_option_name, or store more carefully in catalog?
Date: Sat, 31 May 2025 21:12:53 -0400
Message-ID: <3029560.1748740373@sss.pgh.pa.us> (raw)
In-Reply-To: <683BA390.7000903@acm.org>
References: <6830EB30.8090904@acm.org>
<3020890.1748735715@sss.pgh.pa.us>
<683BA390.7000903@acm.org>
Chapman Flack <jcflack@acm.org> writes:
> On 05/31/25 19:55, Tom Lane wrote:
>> I'm not following that part?
> It's that ISO rule that identifiers match case-insensitively
> if they weren't quoted, case-sensitively if they were.
> We don't explicitly store in catalogs whether quoting was used.
> Clearly it must have been, if the stored form has any non-lowercased letter
> in it, or any non-regular-identifier character. But if we just have foo
> in the catalog, it could have been either of foo or "foo".
I think you're overthinking it. There is one round of dequoting
and downcasing in the grammar, and after that a name is just a
literal string. It's perfectly okay to just store that string and
do exact comparisons to it against other names (which themselves
must have gotten through the grammar). IOW, your claim that there
is a semantic difference between foo and "foo" seems wrong to me.
They are equivalent identifiers.
BTW, I dug around and found that transformRelOptions probably
needs a similar defense. For example:
regression=# create tablespace foo location '/home/postgres/tmp/foo' with ("a=b" = "c=d");
ERROR: unrecognized parameter "a"
It looks like all callers of transformRelOptions immediately
validate the result, so that this case is only a question of
which error message you prefer to get. But I think I'd prefer
something saying that "=" is not allowed in an option name.
> Obviously it's too late to change the existing FDW validator API and break
> everything that uses it. But I wonder if it would be completely crazy to
> just offer a new one: say if your CREATE FOREIGN DATA WRAPPER names a
> validator function with signature (oid classid, oid objid) then that's
> also an acceptable validator function and will be called with classid,
> objid of the provisionally-entered {wrapper,server,table,attribute,
> user mapping} to be validated.
The problem for FDWs is that it may not be okay to find out whether
options are valid at the instant they're entered --- you might not
be able to contact the remote server, for instance.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, jcflack@acm.org
Subject: Re: tighten generic_option_name, or store more carefully in catalog?
In-Reply-To: <3029560.1748740373@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox