default client encoding in postgresql.conf

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