Skip site navigation (1) Skip section navigation (2)

Re: set_client_encoding is broken

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: set_client_encoding is broken
Date: 2009-08-31 18:20:04
Message-ID: 1251742804.1312.143.camel@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane píše v po 31. 08. 2009 v 11:00 -0400:
> 3. Push the startup-packet GUC processing (approx. lines 3340..3395 of
> postgres.c, as of CVS HEAD) into InitPostgres, so it can be run during
> the startup transaction.  This is not too unclean, though it would
> mean exporting process_postgres_switches() from postgres.c; I guess
> the main thing I don't like about it is that InitPostgres has enough
> weird responsibilities already.
> 
> I'm leaning to the third choice, but I wonder if anyone has any
> comments
> or better ideas.

It seems to me that 3 is OK.

Another possibility is that InitPostgres can only fill up rel cache and
GUC processing can stay on the same place. But in general, this problem
can affect any other GUC variable which has assign hook and needs to
lookup. 

I don't know how it works before, but I'm afraid that user can get error
message in server encoding before it is correctly set.


	Zdenek 


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-08-31 18:20:30
Subject: Re: 8.5 release timetable, again
Previous:From: Josh BerkusDate: 2009-08-31 18:16:55
Subject: Re: 8.5 release timetable, again

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group