Re: Do we prefer software that works or software that looks good? - Mailing list pgsql-hackers

On Sat, 24 Apr 2004, Shachar Shemesh wrote:

> Stephan Szabo wrote:
>
> >Are we going to get rid of the current behavior entirely?
> >
> I doubt that will be a good idea. You want to let applications created
> for previous versions of PostgreSQL continue to work. The idea, I think,
> is to have either a DB wide, or a session wide, option to have it either
> way. We may have to create a DB conversion tool, that converts a DB from
> one way to the other (and changes the case of functions, along the way).

I'm going to assume that we're making the assumption that the user isn't
going to try to do this on databases where it doesn't work? I think we've
lost any information about quoting (was that named "foo" or foo?) so I
don't think we can meaningfully make a current PostgreSQL app that's
inconsistent about quoting work after the conversion. I think this is
reasonable, but others may disagree.

> > If so, how are
> >we going to handle issues like current databases with names like foo and
> >"FOO" (and what if the name was given as "foo")?
> >
> I think these are really rare. The conversion tool can warn about these
> cases.

I agree, but we need to think about these cases (and any other wacky cases
like this) so that we can warn about these cases rather than just not
handle them.

> > If not, when can one set
> >the folding options and how do we (in the long term) make the database
> >work properly in both settings.
> >
> I don't think having the same DB work in both folding options is really
> a big issue. Having two databases on the same server, one this way and
> one the other is, however. You don't want to install two database
> servers, merely because you have two applications developed for two
> different PG versions.

To be honest for me, it really doesn't feel much different than an app
written for 7.2 and one written for 7.4 where the former uses things that
were removed and so cannot be moved to 7.4 without changes. But that's
just an option.

> > Things like "don't worry about the catalog
> >entries" don't fly when your standard functions are defined and
> >looked up there.
> >
> >
> Answer above.

Okay, under that world view (as opposed to on the fly), I think the only
issues come in from shared catalogs, most importantly user names.  This is
certainly solvable, but we need to consider how we handle them when given
to commands like ALTER USER or CREATE USER.

> > The fold up and down compare one then the other on a failure of the
> >first may be fairly invasive changes,
> >
> In what way invasive?

Right now AFAIK most of the case folding stuff pretty much happens in one
place during normal queries and the identifier string you get out has the
post-folding identifier for unquoted or the contained literal for quoted.

In a system where you fold both directions, I can see a few
obvious options:a) keep around the real identifier that was given plus whether or  not it was quoted.b) keep around
bothfolded identifiers (for non-quoted names).c) fold one direction then the other.  This may potentially do the
wrongthing in some locales
 

I don't know how you were planning to handle this issue so I don't know if
any of these scenarios were what you were thinking of or if you had a
better idea.  I think all of these potentially may need to touch at least
some places where the identifier is used and I think all of them need
information that is not AFAIK currently returned from scan.l which means
passing that information along (which may change stuff along the way).

> > still has problems when quotes
> >are used inconsistently
> >
> The main issue, as far as I'm concerned, is not with PG apps that need
> to be ported to the new scheme. I don't have any qualm with never
> deprecating the lowercase folding. This, of course, puts a burden on
> utilities that work as infrastructure to always quote or always
> not-quote (depending on exact semantics), but that, I believe, is solveable.
>
> My problem is with applications written for other, more standard
> complient, databases, and with porting these into PG. As such, if the
> app uses inconsistent quoting, it today relies on uppercase folding, and
> will not have any problem.

That sounds like a plus for having the option for full uppercase folding.
I have no problems with that (I wouldn't have even looked at initdb if I
didn't want to give an option for uppercase folding) but I'm not convinced
it actually is a plus for the transitional setting. An app written for
full uppercase should work in said option without needing the transitional
setting and in fact the transitional setting might do the wrong thing for
said application. The only place I can see transitional being useful is
for upgrading and testing our own stuff (make the server work, make
pg_dump work, etc) and for applications moving from supporting only the
lowercase to supporting both or only upper. For the former, it doesn't
need to be a truly supported feature if it's going in in a single version,
and for the latter, I think as many of the wierd change and such issues as
possible are important and need to be considered if only for documentation
purposes.