Re: [HACKERS] client_encoding directive is ignored in
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, client_encoding is defined in postgresql.conf or not, PGCLIENTENCODING is set in postmaster's environment or not, etc)? 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. Anyway I will list up none default behaviors. case 1: PGCLIENTENCODING environment variable is set when postmaster starts up case 2: -c 'client_encoding=some_encoding is set when postmaster starts up case 3: PGOPTIONS environment variable is set frontend starts up case 4: GUC variable client_encoding is set current behavior: show client_encoding shows the encoding set by PGCLIENTENCODING/postmaster opton/PGOPTIONS/GUC variable but actual client encoding is same as the database encoding. Thus pg_client_encoding() returns the database encoding. Also client/database encoding conversion is not peformed(bug). After changes: show client_encoding shows the encoding set by PGCLIENTENCODING/postmaster opton/PGOPTIONS/GUC variable. pg_client_encoding() returns the client encoding as expected. Client/database encoding conversion will be peformed. case 5: PGCLIENTENCODING environment variable is set frontend starts up case 6: SET client_encoding command is issued current behavior: show client_encoding shows the encoding set by PGCLIENTENCODING/SET command. pg_client_encoding() returns the client encoding as expected. Client/database encoding conversion will be peformed. After changes: same as above. -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] client_encoding directive is ignored in
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 that way by default, I guess we won't create any surprises. Okay, I withdraw my objection. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] client_encoding directive is ignored in
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 fix 1) without any backward compatibilty problem and should be applied to both 7.3-STATBLE and current. If we change the backend behavior without changing libpq, aren't we breaking things even worse? As long as libpq behaves as in (2), hadn't the backend better init its idea of client_encoding to match database_encoding? 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. -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] client_encoding directive is ignored in
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? It's probable that libpq itself is not affected by the selected client_encoding, since it only passes data through. But I think that applications are quite likely to be broken if we alter the backend's behavior in a way that changes the default client encoding. That strikes me as a change that should be made at a major release, not a minor one --- people don't expect to get hit by compatibility problems when they do a minor upgrade. 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, client_encoding is defined in postgresql.conf or not, PGCLIENTENCODING is set in postmaster's environment or not, etc)? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] client_encoding directive is ignored in
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 the connection. This is just a mistake. I think we could fix 1) without any backward compatibilty problem and should be applied to both 7.3-STATBLE and current. -- Tatsuo Ishii ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] client_encoding directive is ignored in
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 mistake. I think we could fix 1) without any backward compatibilty problem and should be applied to both 7.3-STATBLE and current. If we change the backend behavior without changing libpq, aren't we breaking things even worse? As long as libpq behaves as in (2), hadn't the backend better init its idea of client_encoding to match database_encoding? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] client_encoding directive is ignored in postgresql.conf
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 pg_client_encoding(); commit)) Doesn't this break compatibility with pre-7.2 databases? AFAICT that function was introduced in 7.2. I haven't seen this patch applied. If this is the best way to fix the bug, we may as well break libpq for pre-7.2 clients. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] client_encoding directive is ignored in
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. ! if (!PQsendQuery(conn, begin; select pg_client_encoding(); commit)) Doesn't this break compatibility with pre-7.2 databases? AFAICT that function was introduced in 7.2. Yes, but there seems no other way to solve the problem and I thought we do not guarantee the compatibilty between 7.3 frontend and pre 7.3 servers. Yep. Tatsuo, you should apply the patch to fix the problem. Shame this didn't make it into 7.3.2. Should we backpatch? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] client_encoding directive is ignored in
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 too short notice. Especially it's not something to spring on people in a dot-release. Put it in 7.4 with a fat compatibility warning in the release notes. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] client_encoding directive is ignored in postgresql.conf
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(); commit)) Doesn't this break compatibility with pre-7.2 databases? AFAICT that function was introduced in 7.2. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
