Re: tighten generic_option_name, or store more carefully in catalog? - Mailing list pgsql-hackers

On 05/31/25 21:12, Tom Lane wrote:
> 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).          ^^^^^ ^^^^^^^^^^
  ^^^^ ^^^^ ^^^^^^ ^^^^^^^ ^^^ ^^^^^^^

Right ... until you're in a situation of comparing it to an identifier
that came to you some other way. The old bug where PL/Java would let
non-superusers change the public-schema class path by spelling public
in different case was possible because the set_classpath function takes
the schema as a string argument. Developers of FDW handlers are likely
to have option names embedded in some kind of PL source code. Those don't
all arrive preprocessed in the same way as those PostgreSQL parsed.

> IOW, your claim that there is a semantic difference between foo
> and "foo" seems wrong to me. They are equivalent identifiers.

I think it is true that I can treat them as equivalent for matching:
it falls in the rule in the spec that says a <regular identifier> and
a <delimited identifier> are equivalent if the case-normal form of the
regular one matches the exact form of the delimited one.

So yes, I did overthink it a tad: if I see foo in the catalog and Foo
in some function argument or PL source code, I do need to know whether
the argument or source literal was intended to represent a regular
or a delimited identifier, but I don't need to know that about the foo
in the catalog. I knew that once and wrote code that knew it, but forgot
for a moment here.

> 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.

Hmm, ok, so is the argument that the provisionally-enter-in-catalog
validation approach wasn't used because a validity verdict might not
be forthcoming right away in the transaction where that is done, and
that this alternate approach of passing some partial information to
a validator in an array solved a problem that would otherwise arise?

I don't think I'm seeing how the one approach ends up better than the
other on that score. If I write test code, it sure seems the validator
as currently implemented gets called at the instant I do the CREATE,
and I'm not sure what else I could imagine happening instead.

Seems like "some options might need server connection to fully check"
is just an inherent, understood limitation no matter how the validator
API is designed. A validator author surely thinks about what checks are
basic sanity checks on syntax and compatibility of different options and
what can be checked locally and what requires a server connection, and
for what options it may be necessary to check the basic syntax and then
say "ok" and hope for the best. Or take the more pessimistic approach and
just reject the declaration and make you try again when the server's up.

But to have to tell a validator author things like, you can't check your
locally-declared table options against what your locally-declared server
options are ... you can't check your column options against your declared
table options, or even what table the column is declared in, or what the
column's locally-declared type is ... your server option validation can't
know anything about the FDW options and the server 'type' and 'version'
aren't even passed to the validator ... just because our API's that way ..,

... things like that seem more like own-goals. Fixing them wouldn't make
the truly inherent limitations go away, but then at least there'd just be
the truly inherent ones.

Regards,
-Chap