Subject: Re: tighten generic_option_name, or store more carefully in catalog?
To: Tom Lane <tgl@sss.pgh.pa.us>
References: <6830EB30.8090904@acm.org> <3020890.1748735715@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Chapman Flack <jcflack@acm.org>
Message-ID: <683BA390.7000903@acm.org>
Date: Sat, 31 May 2025 20:49:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <3020890.1748735715@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/683BA390.7000903%40acm.org>
Precedence: bulk

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