On 05/31/25 19:55, Tom Lane wrote:
> Chapman Flack <jcfl...@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
