On Fri, 19 Jul 2002, Tom Lane wrote: > "scott.marlowe" <[EMAIL PROTECTED]> writes: > > Agreed. Absolutely. But, since the SQL standard says upper case, > > wouldn't it be useful to at least have a switch (run time, initdb time, > > or ./configure time???) called something like FOLDTOUPPER (in upper case > > of course :-) > > The main problem with this is what do you do with the system catalogs? > If we start folding to upper case then existing clients will break > unless we also rename pg_class to PG_CLASS, etc; and that will break > them anyway if they wrote "pg_class". > > I don't believe that conforming to this particular small aspect of the > spec is worth the pain it would cause.
But it's not a small aspect if it means someone either can't use an app with postgresql because it was written to spec, or someone has to spend a bunch of time rewriting all their queries to work with postgresql. I'm not talking about something I'd want on all my tables or all my databases, but there are many instances (look over this list's archive and you'll see them) where following spec would help migration issues. 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. And if you're migrating to postgresql, you won't have anything there that would access pg_* as well. Leave the system catalogs in lower case, and don't fold calls to anything that's a system catalog. Or wrap them all to upper if the fold to upper is set. I don't see this being a setting that many people would change, but then again, most people don't change sql_inheritance or transform_nulls_equals but their both there for the same reason as what I'm talking about. Some other databases do things a little differently, and if we want to be a drop in replacement, we can either accomodate them or thumb our noses at them and tell them it's not our problem. In all honesty, this change is more "right" than transform_nulls_equals since transform_nulls_equals makes postgresql BREAK the SQL standard, and this one would make it follow it. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
