On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
Stephan Szabo wrote:
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.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.
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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
