Thread: 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