Re: Bringing PostgreSQL torwards the standard regarding - Mailing list pgsql-hackers

From scott.marlowe
Subject Re: Bringing PostgreSQL torwards the standard regarding
Date
Msg-id Pine.LNX.4.33.0404271139380.5967-100000@css120.ihs.com
Whole thread Raw
In response to Re: Bringing PostgreSQL torwards the standard regarding case folding  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Bringing PostgreSQL torwards the standard regarding
Re: Bringing PostgreSQL torwards the standard regarding
List 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.



pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: PITR Phase 2 - Design Planning
Next
From: Bruce Momjian
Date:
Subject: Re: bitwise and/or aggregate functions?