On Tue, Jul 08, 2008 at 12:00:34PM +0200, Zdenek Kotala wrote:
> >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 ...
Oh I see, you're referring to the storage of the default collation for
a database. I was jumping ahead to the per-column collation state, when
the collation default is attached to columns, types and domains, and
not at the database level. So there the problem does not exist.
To be honest, I'd suggest storing the collation in pg_database as a
string, rather than as an identifier. This sidesteps the problem
entirly.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.