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).[ Tom, we know your opinion on the first part of the next paragraph, so you don't need to reply to that part. ;) ]
Are we going to get rid of the current behavior entirely?
I think these are really rare. The conversion tool can warn about these cases.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 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.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.
Things like "don't worry about the catalogAnswer above.
entries" don't fly when your standard functions are defined and
looked up there.
I think they do. The idea is to be as complaining and as verbose during transition as possible. Ideally, if some breakpoint can be triggered each time a double lookup takes place (thus knowing that the client app is calling the wrong way), this will allow converting apps in almost no time at all.Depending on the answers to the above, we need to think about things like the transitional plans put forth. Do these plans actually help transition things.
In what way invasive?The fold up and down compare one then the other on a failure of the first may be fairly invasive changes,
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.still has problems when quotes are used inconsistently
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.
and can also silently change behavior from oldI agree. It's just that I don't think this is a big issue, given the fact that I don't think we intend to deprecate the lowercase folding any time soon.
versions (on that database mentioned above, what does select * from foo
do, is it the same as before?). These may or may not be huge issues and it
may or may not be easily solvable, but these things need to be figured out
IMHO before something can be considered a solution.
Shachar
Remove advocacy from the CC. I don't think it's related there any more.
-- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
