Обсуждение: default client encoding in postgresql.conf

looking in my freshly installed 8.3.3, I see this in the postgresql.conf

#client_encoding = sql_ascii            # actually, defaults to database
         # encoding
 

Now, certainly initdb can't know for sure what encoding a future database will 
be in, but since it does know what encoding template0 & friends will be in, 
and most databases are copied from those (including encoding), wouldn't a 
better default be to set it the encoding of template0? 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla@users.sourceforge.net> writes:
> looking in my freshly installed 8.3.3, I see this in the postgresql.conf
> #client_encoding = sql_ascii            # actually, defaults to database
>                                                            # encoding

> Now, certainly initdb can't know for sure what encoding a future database will 
> be in, but since it does know what encoding template0 & friends will be in, 
> and most databases are copied from those (including encoding), wouldn't a 
> better default be to set it the encoding of template0? 

No.  Setting it at all in postgresql.conf is generally the wrong thing;
the right thing is to let the default behavior (ie, make it equal to the
database encoding) happen.
        regards, tom lane

On Thursday 12 June 2008 17:38:26 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > looking in my freshly installed 8.3.3, I see this in the postgresql.conf
> > #client_encoding = sql_ascii            # actually, defaults to database
> >                                                            # encoding
> >
> > Now, certainly initdb can't know for sure what encoding a future database
> > will be in, but since it does know what encoding template0 & friends will
> > be in, and most databases are copied from those (including encoding),
> > wouldn't a better default be to set it the encoding of template0?
>
> No.  Setting it at all in postgresql.conf is generally the wrong thing;
> the right thing is to let the default behavior (ie, make it equal to the
> database encoding) happen.
>

But isn't putting a default that is likely to be wrong just encouraging people 
to set it to something more permanent as an attempt to "correct" this? 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla@users.sourceforge.net> writes:
>>> looking in my freshly installed 8.3.3, I see this in the postgresql.conf
>>> #client_encoding = sql_ascii            # actually, defaults to database
>>> # encoding

> But isn't putting a default that is likely to be wrong just encouraging people 
> to set it to something more permanent as an attempt to "correct" this? 

Huh?  We *aren't* putting in a default.

This conversation is beginning to suggest to me that client_encoding
shouldn't be listed in postgresql.conf at all.
        regards, tom lane

On Thursday 12 June 2008 21:11:57 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> >>> looking in my freshly installed 8.3.3, I see this in the
> >>> postgresql.conf #client_encoding = sql_ascii            # actually,
> >>> defaults to database # encoding
> >
> > But isn't putting a default that is likely to be wrong just encouraging
> > people to set it to something more permanent as an attempt to "correct"
> > this?
>
> Huh?  We *aren't* putting in a default.
>

Right, but when you look in the postgresql.conf, it looks like we are setting 
the default to sql_ascii (since all other default values follow this 
commented setting formula). 

> This conversation is beginning to suggest to me that client_encoding
> shouldn't be listed in postgresql.conf at all.
>

Yeah, that sure seems better than what we currently have. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:
>> This conversation is beginning to suggest to me that client_encoding
>> shouldn't be listed in postgresql.conf at all.
>>
>>     
>
> Yeah, that sure seems better than what we currently have. 
>
>   

I should have thought there was a good argument for preventing its being 
set in postgresql.conf.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Robert Treat wrote:
>>> This conversation is beginning to suggest to me that client_encoding
>>> shouldn't be listed in postgresql.conf at all.
>> 
>> Yeah, that sure seems better than what we currently have. 

> I should have thought there was a good argument for preventing its being 
> set in postgresql.conf.

No, I can think of cases where someone might legitimately want to do
that, they're just pretty far out of mainstream usage.

We already have some variables that are GUC_NOT_IN_SAMPLE but not
GUC_DISALLOW_IN_FILE, so I don't see anything wrong with considering
client_encoding the same way.

(BTW, sometime we ought to get around to enforcing GUC_DISALLOW_IN_FILE...)
        regards, tom lane