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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-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

Browse pgsql-advocacy by date

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

Browse pgsql-hackers by date

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

Browse pgsql-www by date

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