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
