Shouldn't default multibyte encoding come from template database?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Shouldn't default multibyte encoding come from template database?
Date: 2000-11-14 04:31:27
Message-ID: 175.974176287@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-11-14 04:57:50 Re: Shouldn't default multibyte encoding come from template database?
Previous Message Tom Lane 2000-11-14 03:16:07 Re: Re: [PATCHES] PostgreSQL virtual hosting support