Re: [GENERAL] id and ID in CREATE TABLE
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] id and ID in CREATE TABLE |
Дата | |
Msg-id | 15001.1027109813@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-sql |
"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
В списке pgsql-sql по дате отправления: