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