public inbox for [email protected]
help / color / mirror / Atom feedbytea vs standard_conforming_strings
2+ messages / 2 participants
[nested] [flat]
* bytea vs standard_conforming_strings
@ 2006-10-24 01:43 Tom Lane <[email protected]>
2006-11-23 04:28 ` Re: bytea vs standard_conforming_strings Bruce Momjian <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2006-10-24 01:43 UTC (permalink / raw)
To: pgsql-docs
The discussion of bytea in section 8.4,
http://developer.postgresql.org/pgdocs/postgres/datatype-binary.html
is obsolete because it assumes that standard_conforming_strings is
always OFF. It could be very much simpler and shorter if
standard_conforming_strings were always ON, but that's not reality
either. Anyone have an idea on how to rewrite it in a way that
isn't awkward, incomprehensible, or both?
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: bytea vs standard_conforming_strings
2006-10-24 01:43 bytea vs standard_conforming_strings Tom Lane <[email protected]>
@ 2006-11-23 04:28 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2006-11-23 04:28 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-docs
Tom Lane wrote:
> The discussion of bytea in section 8.4,
> http://developer.postgresql.org/pgdocs/postgres/datatype-binary.html
> is obsolete because it assumes that standard_conforming_strings is
> always OFF. It could be very much simpler and shorter if
> standard_conforming_strings were always ON, but that's not reality
> either. Anyone have an idea on how to rewrite it in a way that
> isn't awkward, incomprehensible, or both?
I added two "(assuming <varname>standard_conforming_strings</> is
<literal>off</>)" clauses in the bytea docs. Patch attached, sorry for
the new wrapping.
--
Bruce Momjian [email protected]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
[text/x-diff] /rtmp/diff (4.3K, 2-%2Frtmp%2Fdiff)
download | inline diff:
Index: doc/src/sgml/datatype.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v
retrieving revision 1.180
diff -c -c -r1.180 datatype.sgml
*** doc/src/sgml/datatype.sgml 23 Oct 2006 18:10:30 -0000 1.180
--- doc/src/sgml/datatype.sgml 23 Nov 2006 04:21:46 -0000
***************
*** 1097,1111 ****
</para>
<para>
! When entering <type>bytea</type> values, octets of certain values
! <emphasis>must</emphasis> be escaped (but all octet values
! <emphasis>can</emphasis> be escaped) when used as part of a string
! literal in an <acronym>SQL</acronym> statement. In general, to
! escape an octet, it is converted into the three-digit octal number
! equivalent of its decimal octet value, and preceded by two
! backslashes. <xref linkend="datatype-binary-sqlesc"> shows the
! characters that must be escaped, and gives the alternate escape
! sequences where applicable.
</para>
<table id="datatype-binary-sqlesc">
--- 1097,1113 ----
</para>
<para>
! When entering <type>bytea</type> values, octets of certain
! values <emphasis>must</emphasis> be escaped (but all octet
! values <emphasis>can</emphasis> be escaped) when used as part
! of a string literal in an <acronym>SQL</acronym> statement. In
! general, to escape an octet, it is converted into the three-digit
! octal number equivalent of its decimal octet value, and preceded
! by two backslashes (or one backslash if
! <varname>standard_conforming_strings</> is <literal>off</>).
! <xref linkend="datatype-binary-sqlesc"> shows the characters
! that must be escaped, and gives the alternate escape sequences
! where applicable.
</para>
<table id="datatype-binary-sqlesc">
***************
*** 1168,1191 ****
</para>
<para>
! The reason that you have to write so many backslashes, as shown in
! <xref linkend="datatype-binary-sqlesc">, is that an input string
! written as a string literal must pass through two parse phases in
! the <productname>PostgreSQL</productname> server. The first
! backslash of each pair is interpreted as an escape character by
! the string-literal parser and is therefore consumed, leaving the
! second backslash of the pair. The remaining backslash is then
! recognized by the <type>bytea</type> input function as starting
! either a three digit octal value or escaping another backslash.
! For example, a string literal passed to the server as
! <literal>'\\001'</literal> becomes <literal>\001</literal> after
! passing through the string-literal parser. The
! <literal>\001</literal> is then sent to the <type>bytea</type>
! input function, where it is converted to a single octet with a
! decimal value of 1. Note that the apostrophe character is not
! treated specially by <type>bytea</type>, so it follows the normal
! rules for string literals. (See also <xref
! linkend="sql-syntax-strings">.)
</para>
<para>
--- 1170,1194 ----
</para>
<para>
! The reason that you have to write so many backslashes, as shown
! in <xref linkend="datatype-binary-sqlesc">, is that an input
! string written as a string literal must pass through two parse
! phases in the <productname>PostgreSQL</productname> server.
! The first backslash of each pair is interpreted as an escape
! character by the string-literal parser (assuming
! <varname>standard_conforming_strings</> is <literal>off</>)
! and is therefore consumed, leaving the second backslash of the
! pair. The remaining backslash is then recognized by the
! <type>bytea</type> input function as starting either a three
! digit octal value or escaping another backslash. For example,
! a string literal passed to the server as <literal>'\\001'</literal>
! becomes <literal>\001</literal> after passing through the
! string-literal parser. The <literal>\001</literal> is then sent
! to the <type>bytea</type> input function, where it is converted
! to a single octet with a decimal value of 1. Note that the
! apostrophe character is not treated specially by <type>bytea</type>,
! so it follows the normal rules for string literals. (See also
! <xref linkend="sql-syntax-strings">.)
</para>
<para>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2006-11-23 04:28 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-10-24 01:43 bytea vs standard_conforming_strings Tom Lane <[email protected]>
2006-11-23 04:28 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox