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?
In-reply-to: <683BA390.7000903@acm.org>
References: <6830EB30.8090904@acm.org> <3020890.1748735715@sss.pgh.pa.us>
 <683BA390.7000903@acm.org>
Comments: In-reply-to Chapman Flack <jcflack@acm.org>
	message dated "Sat, 31 May 2025 20:49:20 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3029559.1748740373.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 31 May 2025 21:12:53 -0400
Message-ID: <3029560.1748740373@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3029560.1748740373%40sss.pgh.pa.us>
Precedence: bulk

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 let=
ter
> 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=3D# create tablespace foo location '/home/postgres/tmp/foo' wit=
h ("a=3Db" =3D "c=3Dd");
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 "=3D" is not allowed in an option name.

> Obviously it's too late to change the existing FDW validator API and bre=
ak
> 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