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 :-) Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])