Shouldn't default multibyte encoding come from template database? - Mailing list pgsql-hackers

From Tom Lane
Subject Shouldn't default multibyte encoding come from template database?
Date
Msg-id 175.974176287@sss.pgh.pa.us
Whole thread Raw
Responses Re: Shouldn't default multibyte encoding come from template database?  (Philip Warner <pjw@rhyme.com.au>)
Re: Shouldn't default multibyte encoding come from template database?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I've got the multiple-template-database feature nearly ready to commit,
but I was just noticing that the way we handle default MB encoding
selection seems wrong for this way of looking at things.  Currently,
if you don't specify "ENCODING = something" in CREATE DATABASE, the
default is to use the encoding that applies to the database you're
currently connected to.  Seems to me that it'd make more sense to
default to the encoding used by the DB you're copying.  Comments?

(Of course, there'd be no difference for the common case where you
connect to template1 and then clone template1.)

It's actually a little worrisome that we even allow selection of
encoding during CREATE DATABASE.  If template1 (or any other source
database) contains non-ASCII data such as table or field names,
then the indexes on the system catalogs aren't necessarily in the
right order for a different encoding.  You could get into big trouble
by carelessly asking for a different encoding during CREATE DATABASE.
I don't quite want to prohibit it, since usually template1 doesn't
contain any non-ASCII data.  But this certainly seems like a good reason
for making the default behavior be to copy the encoding of the database
you're copying.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [PATCHES] PostgreSQL virtual hosting support
Next
From: Philip Warner
Date:
Subject: Re: Shouldn't default multibyte encoding come from template database?