From: Chapman Flack <jcflack@acm.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: tighten generic_option_name, or store more carefully in catalog?
Date: Sat, 31 May 2025 20:49:20 -0400
Message-ID: <683BA390.7000903@acm.org> (raw)
In-Reply-To: <3020890.1748735715@sss.pgh.pa.us>
References: <6830EB30.8090904@acm.org>
<3020890.1748735715@sss.pgh.pa.us>
On 05/31/25 19:55, Tom Lane wrote:
> Chapman Flack <jcflack@acm.org> writes:
>> SQL rules would also make its case-sensitivity dependent on faithfully
>> recovering whether it was delimited or not.
>
> 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".
Which makes me a little sad because if I provide a way for someone to, say,
check FDW options in Java, and they spell an option FOO in their code,
I would ideally like to report OPTIONS (foo 'bar') as matching and
OPTIONS("foo" 'bar') as not matching. But the information I could use
to do that just isn't there.[0]
Since writing that email, I've stumbled onto more things that seem a bit
bizarre about the FDW extension API, and written about them here -> [1].
(I can't make an internal link anchor there that works, but it's a short
scroll down to the "Notes on the validator function" heading.)
I was surprised that FDW validators weren't designed the same way as
PL validators (just provisionally put the object in the catalog,
then say "validate this oid", and if the validator throws an error
the object goes away). That would have avoided all the funky shortcomings
I just wrote about.
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.
Regards,
-Chap
[0] It's possible I'm hyperattentive to that sort of thing because
IIRC there was an old PL/Java CVE where we wouldn't let a non-superuser
change the Java class path on the public schema, but if she spelled
it puBlIc it was ok. (The function got the schema name as text.)
[1] https://github.com/tada/pljava/issues/430#issuecomment-2921101005
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: jcflack@acm.org, tgl@sss.pgh.pa.us
Subject: Re: tighten generic_option_name, or store more carefully in catalog?
In-Reply-To: <683BA390.7000903@acm.org>
* 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