Re: [HACKERS] What can we learn from MySQL?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Shachar Shemesh <psql(at)shemesh(dot)biz>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: 2004-04-24 04:11:16
Message-ID: 7305.1082779876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-www

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> To clarify, I'm thinking about things where an application had gotten a
> quoted name and is now trying to use it where the object's canonical name
> was changed due to quoting changes. This only happens when quoting
> is inconsistently applied, but that's most of the problem.

Actually, that's *all* the problem, at least as far as SQL commands are
concerned. If you are consistent about always quoting or never quoting
a particular name, you can't tell the difference between PG's behavior
and SQL-spec behavior.

Aside from the reality that apps aren't very consistent about their
quoting behavior, the fly in this ointment is that whenever you query
the database catalogs you will see the stored spelling of the name.
So apps that rely on seeing the same spelling in the catalog that they
entered could break. (In practice this doesn't seem to be as big a
problem as the sloppy-quoting-behavior issue, though.)

Personally I don't think that this is a "transitional issue" and we will
someday all be happy in upper-case-only-land. Upper-case-only sucks,
by every known measure of readability, and I don't want to have to put up
with a database that forces that 1960s-vintage-hardware mindset on me.
So what I'm holding out for is a design that lets me continue to see the
current behavior if I set a GUC variable that says that's what I want.
This seems possible (not easy, but possible) if we are willing to
require the choice to be made at compile time ... but that sounds too
restrictive to satisfy anybody ... what we need is a design that
supports such a choice per-session, and I dunno how to do that.

regards, tom lane

PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
to make the point about readability. But if you want to argue the
point with me, I'll be happy to do that for the rest of the thread.

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Dennis Bjorklund 2004-04-24 04:38:58 Re: [HACKERS] What can we learn from MySQL?
Previous Message Robert Treat 2004-04-23 23:55:16 Re: [pgsql-advocacy] What can we learn from MySQL?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-04-24 04:27:14 Re: Current CVS tip segfaulting
Previous Message Marc G. Fournier 2004-04-24 03:11:36 Re: contrib vs. gborg/pgfoundry for replication solutions

Browse pgsql-www by date

  From Date Subject
Next Message Dennis Bjorklund 2004-04-24 04:38:58 Re: [HACKERS] What can we learn from MySQL?
Previous Message Fred Moyer 2004-04-24 01:19:21 Re: First two requests for PUGs