Skip site navigation (1) Skip section navigation (2)

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [pgsql-advocacy] What can we learn from MySQL?
Date: 2004-04-23 18:28:10
Message-ID: 4089603A.6050904@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-www
Robert Treat wrote:

>On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
>  
>
>>Stephan Szabo wrote:
>>
>>    
>>
>>>>I know this to be true, but don't fully understand it... if our default
>>>>behavior is to fold lower, and we change it to just fold upper... then
>>>>in theory this shouldn't break anything since what used to be folder
>>>>lower will now simply be folder upper. the only people who will have a
>>>>problem are those who quote on one end but not the other, which is bad
>>>>practice anyways...  so i would say if your serious about it, make the
>>>>patch as GUC "case_folding" for upper or lower and get a taste for what
>>>>breaks inside the db.
>>>>   
>>>>
>>>>        
>>>>
>>>I've tried just changing the parser to unconditionally casefold to upper.
>>>First thing that happens is that initdb breaks. In addition, you have
>>>potential issues with comparisons against the catalog's versions of
>>>standard functions as such if you allow the case folding to be changed
>>>after the catalogs are setup.
>>>
>>> 
>>>
>>>      
>>>
>>ISTM that rather than a having a GUC setting, initdb would be the right 
>>time to make this choice. I'm not saying it would be easy, but it seems 
>>(without looking into it deeply) at least possible.
>>
>>    
>>
>
>This implies that the standard functions are created with explicit
>quoting to make the lower case named?  Shouldn't all functions be
>created without any quoting so they fold to whichever way the settings
>are set?  Hmm... I see your angle Andrew.. they are going to be created
>one way or the other so you'd be hard pressed to do it at any time other
>than initdb time... of course you could just create duplicates of all
>the functions in both upper and lower case, that way whichever way you
>fold it matches :-)
>
>  
>

That strikes me as an instant recipe for shooting yourself in the foot, 
as well as providing useless catalog bloat. Things need *one* canonical 
name, IMNSHO.

cheers

andrew

In response to

Responses

pgsql-www by date

Next:From: J. Andrew RogersDate: 2004-04-23 18:56:42
Subject: Re: What can we learn from MySQL?
Previous:From: Robert TreatDate: 2004-04-23 18:27:59
Subject: Re: What can we learn from MySQL?

pgsql-hackers by date

Next:From: Bob.HenkelDate: 2004-04-23 18:30:55
Subject: Re: PITR, nested transactions, tablespaces, 2-phase commit:
Previous:From: Robert TreatDate: 2004-04-23 18:27:59
Subject: Re: What can we learn from MySQL?

pgsql-advocacy by date

Next:From: J. Andrew RogersDate: 2004-04-23 18:56:42
Subject: Re: What can we learn from MySQL?
Previous:From: Robert TreatDate: 2004-04-23 18:27:59
Subject: Re: What can we learn from MySQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group