Re: Some 8.4 changes needed according to pg_migrator testing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some 8.4 changes needed according to pg_migrator testing
Date
Msg-id 11807.1241807982@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some 8.4 changes needed according to pg_migrator testing  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Some 8.4 changes needed according to pg_migrator testing  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Heikki Linnakangas wrote:
>> If we go with that, we should probably make the notion of a default  
>> collation explicit. We could set pg_database.datcollate/datctype column  
>> to NULL to mean "use the cluster default".

> I'm not sure how this would work.  If I initdb with a certain
> locale/encoding and then create a database with default locale/encoding,
> how would a restore work on a cluster that has been initdb'd with a
> different locale/encoding?  If you don't dump the locale specification,
> it could very well not match what the user intended.

As Peter suggested, that's more or less the point.  As long as we still
have pg_dump output include the client_encoding setting, it is sensible
to try to load a dump into a different default database encoding/locale;
and in fact you can not guarantee that the new platform's locales behave
exactly the same anyway.

One problem that just occurred to me is that this solution may not be
adequate for pg_migrator.  It will need to check that the new database
has the same "default" settings (where "default" means "those of
template0") as the old installation did.  I think that's probably doable
but we'll have to check.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Some 8.4 changes needed according to pg_migrator testing
Next
From: Greg Smith
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench