Re: Bringing PostgreSQL torwards the standard regarding

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Shachar Shemesh <psql(at)shemesh(dot)biz>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bringing PostgreSQL torwards the standard regarding
Date: 2004-04-27 17:43:54
Message-ID: Pine.LNX.4.33.0404271139380.5967-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 26 Apr 2004, Josh Berkus wrote:

> Shachar,
>
> > I think the concensus was that the runtime part was aprox. four lines
> > where the case folding currently takes place. Obviously, you would have
> > to get a var, and propogate that var to that place, but not actually
> > change program flow.
>
> That's only if you ignore the system catalogs entirely, which maybe you're
> prepared to do. If you want to change case folding for the system catalogs,
> though, you'll need to update code in thousands of places, becuase the
> back-end code is expecting lower-case identifiers ....

As someone who has discussed this with Tom in the past, I seem to remember
that there were major issues with handling the system catalogs, because
internally, the backends treat the identifiers as if they have already
been quoted.

I think the answer to all of this would require a lot of code being
touched to either make it case fold, costing performance, or the
replacement of the default lower cased catalog with upper cased catalog.

i.e. no simple switch setting, but an initdb option that would be set like
locale currently is, for the life of the cluster.

A more comprehensive solution, one which allowed switching from upper
folding to lower folding to no folding, to case insensitive, or some
subset of those possibilities results in

a: slower backend performance, due to folding case for system catalogs
b: touching a helluva lot of backend code to make it possible to fold up
or down.

I'm not 100% sure on this all, but that seems to be the point Tom and I
came to in our discussion, and neither of the two solutions seemed very
good at the time.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim Conrad 2004-04-27 17:49:22 Re: Upcoming Features WAS: What can we learn from MySQL?
Previous Message Bruno Wolff III 2004-04-27 17:43:25 Re: PITR Phase 2 - Design Planning