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  (Andrew Dunstan <andrew@dunslane.net>)
Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers  (Russell Smith <mr-russ@pws.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_dump additional options for performance
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers