TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers
От | Russell Smith |
---|---|
Тема | TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers |
Дата | |
Msg-id | 47E6F10D.5070601@pws.com.au обсуждение исходный текст |
Ответы |
Re: TODO Item: Consider allowing control of upper/lower
case folding of unquoted, identifiers
Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers |
Список | pgsql-hackers |
Hi, As an attempt at a first PostgreSQL patch, I'd like to see if I can do anything about this issue. I've read both the attached threads; http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php There seems no consensus about how to go about this. I have done some initial changes and found some problems with my attempts. initdb always creates pg_catalog relations with lowercase names, as does the function list. eg count() with uppercased identifiers requires "count"(). All of these can be altered on database copy. It shouldn't be a problem. However I see shared relations as a big problem. The 2004 thread suggests that we want a per database setting. I am unable to see how we share shared relations between databases with different case folder. pg_user is an example of this; Lowercase database; CREATE ROLE mrruss LOGIN; results in -> mrruss as data in pg_user Uppercase database; CREATE ROLE mrruss LOGIN; resutls in -> MRRUSS as data in pg_user Now both of those can be accessed from any database. And you will get a different user based on the source database. Overall, I'd like to concentrate on the implementation as I'm a beginner. But I see this being mainly a problem with nailing down the actual requirement for the implementation. So I'll try to start the discussion to allow me or somebody else to eventually develop a patch for this. The first question is, are all the requirements of the 2004 thread still true now? Setting case folder at initdb time seems the easiest method but I'm not sure if that's what people want. Any GUC variables seem to play havoc with the pg_catalog schema and the data in the catalogs. Ideas and comments? Thanks Russell
В списке pgsql-hackers по дате отправления: