Re: [SQL] id and ID in CREATE TABLE

On Fri, 19 Jul 2002, Tom Lane wrote:

> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> 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.