Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 11BBF1337B92 for ; Thu, 3 Feb 2011 15:56:24 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 01884-05 for ; Thu, 3 Feb 2011 19:56:16 +0000 (UTC) Received: from news.hub.org (news.hub.org [200.46.204.72]) by mail.postgresql.org (Postfix) with ESMTP id B29F9133740B for ; Thu, 3 Feb 2011 15:56:16 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.4/8.14.4) with ESMTP id p13JuGa5020544 for ; Thu, 3 Feb 2011 15:56:16 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.4/8.14.4/Submit) id p13Jc7bM085234 for pgsql-docs@postgresql.org; Thu, 3 Feb 2011 15:38:07 -0400 (AST) (envelope-from news) From: ljb X-Newsgroups: pgsql.docs Subject: Re: [GENERAL] Gripe: bytea_output default => data corruption Date: Thu, 3 Feb 2011 19:38:07 +0000 (UTC) Organization: Hub.Org Networking Services Lines: 23 Message-ID: References: <201102022125.p12LPqd03573@momjian.us> <201102022127.p12LRnZ04134@momjian.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: slrn/0.9.9p1 (Linux) To: pgsql-docs@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/17 X-Sequence-Number: 6365 bruce@momjian.us wrote: >... >> Based on this report, I have created the attached documentation patch >> which clarifies the libpq behavior for escaping bytea. I am planning to >> backpatch this to 9.0 as well. This change says PQescapeBytea is unable to adjust its behavior based on bytea_output, implying that PQescapeByteaConn does adjust its behavior based on byte_output. Wrong! Neither one knows or cares about the bytea_output parameter, which is solely for the backend to tell it how to present bytea data to the front-end. Not for the front-ends at all. (See why we need this behavior documented?) Non-use of 'standard_conforming_strings' is also wrong, in the current (pre-patched) docs. PQescapeBytea does adjust its behavior for standard_conforming_strings, but only for the single-connection case. See similar text for PQescapeString. Regarding the first paragraph changed, it seems off to me. "PQescapeByteConn escapes such bytes using either hex encoding..." tells me that when hex encoding is used, PQescapeByte encodes only bytes that need escaping. Not true - hex encoding encodes (not escapes) every byte.