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(at)fts(dot)net

F Harvell <fharvell(at)fts(dot)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

Tom Lane wrote:
> F Harvell <fharvell(at)fts(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)CERT(dot)Uni-Stuttgart(dot)DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898

Florian Weimer <Weimer(at)CERT(dot)Uni-Stuttgart(dot)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