Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> The database encoding is set to the encoding when the database was
> created and the default value of the client encoding is set to same as
> the database encoding. This behavior will not be changed by the change
> I proposed.
As long as it still behaves
> But this argument is mostly irrelevant if the proposed change will not
> affect behavior in a default installation. I guess I'm not entirely
> clear on exactly which cases it will affect. What will your proposed
> change do in each possible combination (database encoding is SQL_ASCII
> or not,
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Why? No matter how the backend's behavior regarding client_encoding
> changes, libpq won't be affected by it since 7.2 and 7.3 libpq does
> not use client_encoding anyway.
Doesn't client_encoding determine what encoding the backend sends to
the client?
I
> > Actually the problem can be divided into two parts:
> > 1) backend does not process GUC client_encoding.
> > 2) libpq does not ask the backend's client_encoding, instead it asks
> >datanbase encoding when it starts up the connection. This is just a
> >mistake.
>
> > I think we could f
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Actually the problem can be divided into two parts:
> 1) backend does not process GUC client_encoding.
> 2) libpq does not ask the backend's client_encoding, instead it asks
>datanbase encoding when it starts up the connection. This is just a
>mis
> OK, can we better document that GUC client_encoding is broken, then fix
> in 7.4?
Actually the problem can be divided into two parts:
1) backend does not process GUC client_encoding.
2) libpq does not ask the backend's client_encoding, instead it asks
datanbase encoding when it starts up t
OK, can we better document that GUC client_encoding is broken, then fix
in 7.4?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yep. Tatsuo, you should apply the patch to fix the problem. Shame this
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yep. Tatsuo, you should apply the patch to fix the problem. Shame this
> didn't make it into 7.3.2. Should we backpatch?
No. I'm not happy that we're breaking libpq for pre-7.2 servers, and
I definitely don't want to see it done in 7.3. That's way t
Tatsuo Ishii wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > + /* Flag to we need to initialize client encoding info */
> > > + static bool need_to_init_client_encoding = -1;
> >
> > Surely that should be int, not bool.
>
> Oops. Will fix.
>
> > > !
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > + /* Flag to we need to initialize client encoding info */
> > + static bool need_to_init_client_encoding = -1;
>
> Surely that should be int, not bool.
>
> > ! if (!PQsendQuery(conn, "begin; select
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > + /* Flag to we need to initialize client encoding info */
> > + static bool need_to_init_client_encoding = -1;
>
> Surely that should be int, not bool.
Oops. Will fix.
> > ! if (!PQsendQuery(conn, "begin; select
>
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> + /* Flag to we need to initialize client encoding info */
> + static bool need_to_init_client_encoding = -1;
Surely that should be int, not bool.
> ! if (!PQsendQuery(conn, "begin; select
>pg_client_encoding(); commi
There is a nasty bug with the client_encoding directive in
postgresql.conf. It is simply ignored. This bug exists in both 7.3 or
later and in current. Interesting thing is "show client_encoding"
command shows expected encoding but this only shows the GUC internal
variable and the actual internal en
13 matches
Mail list logo
