Re: [pgsql-advocacy] What can we learn from MySQL? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [pgsql-advocacy] What can we learn from MySQL?
Date
Msg-id 20040424154022.GA2927@dcc.uchile.cl
Whole thread Raw
In response to Re: [pgsql-advocacy] What can we learn from MySQL?  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote:
> Tom Lane wrote:
> >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.)
> 
> Shouldn't apps only really be querying the information schema if they're 
> expecting spec compliant behavior? If so, a GUC variable with an access 
> function ought to be enough to get up or down casing as desired, I'd think.

Some questions:

Is there a way to make this work?  At what level should the current
system be modified?  If the parser or lexer is to be modified, are they
going to need database access?  They are not allowed to, AFAIR.

One could invent a GUC setting for this, and have it set at database
creation time.  How would shared catalogs be handled?  Should we have a
template database for uppercase and another one for lower case
databases?  Should non-shared catalogs be handled in a special way?

Or maybe it is a compilation switch.  What issues would arise?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are."  -- Charles J. Sykes' advice to teenagers


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: contrib/trgm beta release
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions