Tom Lane writes:
> Could we make the assumption that table names in catalogs
> will be of type 'name'?
I wouldn't want to guarantee it for the information schema.
> If so, it'd work to make two versions of the has_table_privilege
> function, one taking type "name" and the other taking type "text".
> The "name" version would take its input as-is, the "text" version
> would do case folding and truncation.
Target typing is ugly.
I've tried to look up the supposed \paraphrase{we had enough problems
before we added the existing behaviour to setval, etc.} discussion but
couldn't find it. My experience on the mailing list is that it goes the
other way.
The identifier quoting rules are already surprising enough for the
uninitiated, but it's even more surprising that they even apply when
syntactically no identifier is present. Between the behaviour of "what
you see is what you get" and "this language is kind of confusing so you
have to quote your strings twice with two different quoting characters"
the choice is obvious to me.
I'm also arguing for consistency with the standard. According to that,
users will be able to do
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'SoMeThInG';
and a load of similar queries. You can't change the case folding rules
here unless you really want to go out of your way, and then you have
really confused the heck out of users.
We could make relname.func() work without breaking compatibility, ISTM,
and then we only need the Oid version. For computing the relation name at
execution time, the "plain" version is going to be more useful anyway.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
