"scott.marlowe" <scott.marlowe@ihs.com> writes:
> Plus the pg_class stuff is kind of a blind ally. If we're looking at
> foldtoupper as a setting, then we're already admitting that we're doing it
> to be interchangable with other dbmses. If that's the case, no one is
> gonna be accessing the pg_* tables, because you wouldn't do that in an app
> you're writing to be portable.
<< thinks about that for awhile >>
Hmm. If we are willing to stipulate that the system catalogs stay named
as they are (lower case always), then we could indeed have a runtime
parameter (GUC setting) that controls how individual sessions fold case.
People who need to access the system catalogs regardless can just
double-quote their names.
One fly in the ointment is that we are planning to add the standard's
INFORMATION_SCHEMA views someday, and neither choice of case is going to
be good for them if we have an option like this floating around. Not
sure what to do about that, although I suppose one way out is to provide
two duplicate sets of those views (one named all-upper-case, the other
all-lower).
I think your four-way proposal is gilding a dead lily, though. Let's
just do the historical (downcase) and spec-compatible (upcase) options.
Anything else will just create more confusion, IMHO. The
case-insensitive option is a particularly *bad* idea.
Note it would be a real good idea to fix psql and pg_dump to
double-quote their references to system catalogs, so they don't go
belly-up if invoked on a database where FOLDTOUPPER is true.
(pg_dump could alternatively do SET FOLDTOUPPER = false, but this won't
fly for psql.)
> Leave the system catalogs in lower case, and don't fold calls to anything
> that's a system catalog.
And you will determine that how, exactly, when you don't know what the
identifier (that you haven't parsed yet) refers to?
Keep it simple, or you'll make things far worse than they are now.
regards, tom lane