Thread
-
Re: non-standard escapes in string literals
F Harvell <fharvell@fts.net> — 2002-04-25T17:30:34Z
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
-
Re: non-standard escapes in string literals
Tom Lane <tgl@sss.pgh.pa.us> — 2002-04-25T19:07:44Z
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
-
Re: non-standard escapes in string literals
Bruce Momjian <pgman@candle.pha.pa.us> — 2002-04-25T20:22:10Z
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
-
Re: non-standard escapes in string literals
Florian Weimer <weimer@cert.uni-stuttgart.de> — 2002-05-03T21:58:07Z
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
-
Re: non-standard escapes in string literals
Tom Lane <tgl@sss.pgh.pa.us> — 2002-05-03T22:29:04Z
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