Joel Jacobson <j...@trustly.com> writes:
> I think a good general philosophy for the PostgreSQL project would be to
> try to look at how to meed the needs for new users of new projects
> in a way that don't impair things for existing users,
Yeah, exactly, and the problem here is that claiming that something
like this doesn't impact existing users is just ignoring reality.
At the minimum, every author of a driver or other client-side tool
is going to have to try to figure out how to make their code work
with all the possible case-folding rules. They don't have the option
of ignoring server-side changes in the language.
That's why I alluded upthread to the old "server-side-autocommit" fiasco.
That too was sold to us using the argument that it wouldn't impact people
who didn't turn it on. It took about a year for the full scope of the
damage to become apparent, and the end result was that we took the feature
out again. I haven't yet seen an alternate-case-folding proposal that
wouldn't likely end up as the same kind of failure.
The versions of autocommit that have actually stood the test of time were
implemented on the client side (in psql and JDBC, and I think ODBC as
well), where the scope of affected code was lots smaller. I wonder
whether there's any hope of providing something useful for case-folding
in that way. psql's lexer is already smart enough that you could teach it
rules like "smash any unquoted identifier to lower case" (probably it
would fold keywords too, but that seems OK). That's probably not much
help for custom applications, which aren't likely to be going through
psql scripts; but the fact that such behavior is in reach at all on the
client side seems encouraging.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
