Re: [WIP] patch - Collation at database level
От | Zdenek Kotala |
---|---|
Тема | Re: [WIP] patch - Collation at database level |
Дата | |
Msg-id | 48733AC2.5050404@sun.com обсуждение исходный текст |
Ответ на | Re: [WIP] patch - Collation at database level (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: [WIP] patch - Collation at database level
Re: [WIP] patch - Collation at database level |
Список | pgsql-hackers |
Martijn van Oosterhout napsal(a): > On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote: >> Zdenek Kotala napsal(a): >> >>> I though more about it and I discussed it with Radek yesterday. The >>> problem is that collation must be created before user want to use CREATE >>> DATABASE ... COLLATE ... command. It inclines to have have pg_collation >>> as a global catalog, but ANSI specifies to use schema name in collation >>> specification and schemes are database specific ... It means that >>> pg_collation have to be non-shared catalog and new database only >>> inherits collation from template db. And CREATE DATABASE have to check >>> list of collation in template database :(. >> thinking more ... >> It must be shared catalog because pg_database will depend on it. > > Not necessarily. pg_class is not shared yet without it you can't even > find pg_database. Same deal with pg_type. All it means is that > pg_collation in template1 must contain all the collations used in > template1, which shouldn't be hard to arrange. I think, Collation situation is different, becasue pg_database will contains column colname. pg_class (and all bootstrap catalog) only contains row which specify that shared table exists and content is cloned to the new database from template database. In corner case you can get context specific dependency for example if Czech collation will have oid=10 in database test01 and Swedish collation will have oid=10 in database test02. How to handle CREATE DATABASE and connect database? OK it shouldn't happen in normal situation but ... Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
В списке pgsql-hackers по дате отправления: