public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Stephan Szabo <[email protected]>
Cc: Shachar Shemesh <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Dennis Bjorklund <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL advocacy <[email protected]>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: Sat, 24 Apr 2004 00:11:16 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<1082735128.22969.1106.camel@camel>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Stephan Szabo <[email protected]> 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.

view thread (145+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] What can we learn from MySQL?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox