Thread: Shouldn't default multibyte encoding come from template database?

Shouldn't default multibyte encoding come from template database?

From
Tom Lane
Date:
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


Re: Shouldn't default multibyte encoding come from template database?

From
Philip Warner
Date:
At 23:31 13/11/00 -0500, Tom Lane wrote:
>Seems to me that it'd make more sense to
>default to the encoding used by the DB you're copying.  Comments?

Definitely. Especially when/if people start using 'WITH TEMPLATE' for more
databases.


>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

It is probably woth issuing a NOTICE or WARNING when the requested encoding
is different to the template.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Re: Shouldn't default multibyte encoding come from template database?

From
Peter Eisentraut
Date:
Tom Lane writes:

> 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.

How so?
               | CREATE DATABASE database_name                               {
CreatedbStmt*n = makeNode(CreatedbStmt);                                       n->dbname = $3;
            n->dbpath = NULL;                                       n->encoding = GetTemplateEncoding();
                      $$ = (Node *)n;                                }
 

Or does GetTemplateEncoding() not get the template encoding?

In any case, it should, because that's how it used to work and how it's
documented.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: Shouldn't default multibyte encoding come from template database?

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> How so?
> Or does GetTemplateEncoding() not get the template encoding?

GetTemplateEncoding gets the current DB's encoding.  I think that
may have been because of a hack replacing a kluge ;-) ... but that's
how it works now.

Assuming that it did once produce template1's encoding, that would
seem to be further evidence in favor of my proposal to copy the
source (template) database's encoding.
        regards, tom lane