From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Some 8.4 changes needed according to pg_migrator testing |
Date: | 2009-05-08 18:16:06 |
Message-ID: | 11320.1241806566@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote:
>> How about only outputting the LC_COLLATE/CTYPE options for databases
>> that use a non-default setting?
> That was my latest thinking as well.
Logically we should handle database encoding the same way, no?
I'm not really satisfied with this as a long-term solution, but it may
be the most we can hope to squeeze into 8.4. I'm willing to go make the
pg_dumpall changes if there are not objections/better ideas.
>> 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 don't find that to be a good idea, mainly because there *is* no
"cluster default" anymore. I think it's okay for pg_dumpall to treat
the template0 settings as being the "default" for its purposes, but keep
in mind that there is nothing much stopping a DBA from replacing
template0 with another DB that has different settings. We can't have
that break existing DBs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-05-08 18:30:17 | Re: Some 8.4 changes needed according to pg_migrator testing |
Previous Message | Seth Robertson | 2009-05-08 17:47:28 | Re: [PATCH] Automatic client certificate selection support for libpq v1 |