I posted this some time ago to pgsql-bugs[1], to no response.  So
I'll venture to try here.

Postgres breaks the standard for string literals by supporting
C-like escape sequences.  This causes pain for people trying to
write portable applications.  Is there any hope for an option to
follow the standard strictly?

Cc's of replies appreciated.

Thanks,
Andrew

[1] http://archives.postgresql.org/pgsql-bugs/2001-12/msg00048.php

Wed, 24 Apr 2002 14:29:28 -0400
pimlott@idiomtech.com (Andrew Pimlott)
non-standard escapes in string literals
Andrew Pimlott wrote:
> I posted this some time ago to pgsql-bugs[1], to no response.  So
> I'll venture to try here.
> 
> Postgres breaks the standard for string literals by supporting
> C-like escape sequences.  This causes pain for people trying to
> write portable applications.  Is there any hope for an option to
> follow the standard strictly?

This is actually the first time this has come up (that I remember).  We
do support C escaping, but you are the first to mention that it can
cause problems for portable applications.

Anyone else want to comment?  I don't know how to address this.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 Apr 2002 10:41:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: non-standard escapes in string literals
On Thu, 25 Apr 2002 10:41:56 EDT, Bruce Momjian wrote:
> Andrew Pimlott wrote:
> > I posted this some time ago to pgsql-bugs[1], to no response.  So
> > I'll venture to try here.
> > 
> > Postgres breaks the standard for string literals by supporting
> > C-like escape sequences.  This causes pain for people trying to
> > write portable applications.  Is there any hope for an option to
> > follow the standard strictly?
> 
> This is actually the first time this has come up (that I remember).  We
> do support C escaping, but you are the first to mention that it can
> cause problems for portable applications.
> 
> Anyone else want to comment?  I don't know how to address this.

IMHO, I agree that I would like to see the ANSI standard implemented.

While I really like PostgreSQL, it currently does not scale as large
as other DBMS systems.  Due to this, we try to code as database
agnostic as possible so that a port requires a minimum of effort.
Currently there are only a few areas remaining that are at issue.
(Intervals and implicit type conversion have/are being addressed).

I believe that the reason that it hasn't come up as an issue, per se,
is that it would only affect strings with a backslash in them.
Backslash is not a commonly used character.  In addition, MySQL, also
broken, uses backslashes in the same/similar way.  Lots of people
using PostgreSQL are stepping up from MySQL.

This also poses the biggest problem in terms of legacy compatibility.
Perhaps the answer is to add a runtime config option (and default it
to ANSI) and possibly deprecate the C escaping.

Thanks,
F Harvell

-- 
Mr. F Harvell                          Phone: +1.407.673.2529
FTS International Data Systems, Inc.    Cell: +1.407.467.1919
7457 Aloma Ave, Suite 302                Fax: +1.407.673.4472
Winter Park, FL 32792                 mailto:fharvell@fts.net



Thu, 25 Apr 2002 13:30:34 -0400
F Harvell <fharvell@fts.net>
Re: non-standard escapes in string literals 
F Harvell <fharvell@fts.net> writes:
> This also poses the biggest problem in terms of legacy compatibility.
> Perhaps the answer is to add a runtime config option (and default it
> to ANSI) and possibly deprecate the C escaping.

While I wouldn't necessarily object to a runtime option, I do object
to both the other parts of your proposal ;-).  Backslash escaping is
not broken; we aren't going to remove it or deprecate it, and I would
vote against making it non-default.

			regards, tom lane

Thu, 25 Apr 2002 15:07:44 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: non-standard escapes in string literals 
Tom Lane wrote:
> F Harvell <fharvell@fts.net> writes:
> > This also poses the biggest problem in terms of legacy compatibility.
> > Perhaps the answer is to add a runtime config option (and default it
> > to ANSI) and possibly deprecate the C escaping.
> 
> While I wouldn't necessarily object to a runtime option, I do object
> to both the other parts of your proposal ;-).  Backslash escaping is
> not broken; we aren't going to remove it or deprecate it, and I would
> vote against making it non-default.

Added to TODO:

 * Allow backslash handling in quoted strings to be disabled for portability

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 Apr 2002 16:22:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: non-standard escapes in string literals
On Thu, 25 Apr 2002 15:07:44 EDT, Tom Lane wrote:
> F Harvell <fharvell@fts.net> writes:
> > This also poses the biggest problem in terms of legacy compatibility.
> > Perhaps the answer is to add a runtime config option (and default it
> > to ANSI) and possibly deprecate the C escaping.
> 
> While I wouldn't necessarily object to a runtime option, I do object
> to both the other parts of your proposal ;-).  Backslash escaping is
> not broken; we aren't going to remove it or deprecate it, and I would
> vote against making it non-default.
> 

Sorry, didn't mean to imply that backslash escaping was broken, just
non-compliant.  Beyond that, your recommendations are also probably
the best course of action.

I do desire that the "default" operation of the database be as ANSI
standard compliant as possible, however, I certainly understand the
need to be as backwards compliant as possible.  The only issue that I
can see with keeping the backslash escaping default is that new,
non-PostgreSQL programmers will not be expecting the escaping and will
be potentially blindsided by it.  (A bigger deal since backslashes are
unusual and are not often tested for/with.)  Perhaps prominent notice
in the documentation will be adequate/appropriate.  Maybe a section on
differences with the ANSI standard should be created.  (Is there
currently a compilation of differences anywhere or are they all
dispersed within the documentation?).

Thanks,
  F

-- 
Mr. F Harvell                          Phone: +1.407.673.2529
FTS International Data Systems, Inc.    Cell: +1.407.467.1919
7457 Aloma Ave, Suite 302                Fax: +1.407.673.4472
Winter Park, FL 32792                 mailto:fharvell@fts.net



Thu, 25 Apr 2002 17:31:36 -0400
F Harvell <fharvell@fts.net>
Re: non-standard escapes in string literals 
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Added to TODO:
>
>  * Allow backslash handling in quoted strings to be disabled for portability

BTW, what about embedded NUL characters in text strings? ;-)

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Fri, 03 May 2002 23:58:07 +0200
Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Re: non-standard escapes in string literals
Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> writes:
> BTW, what about embedded NUL characters in text strings? ;-)

There's approximately zero chance of that happening in the foreseeable
future.  Since null-terminated strings are the API for both the parser
and all datatype I/O routines, there'd have to be a lot of code changed
to support this.  To take just one example: strcoll() uses
null-terminated strings, therefore we'd not be able to support
locale-aware text comparisons unless we write our own replacement for
the entire locale library.  (Which we might do someday, but it's not
a trivial task.)

The amount of pain involved seems to far outweigh the gain...

			regards, tom lane

Fri, 03 May 2002 18:29:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: non-standard escapes in string literals 