Re: Backslashes in string literals - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Backslashes in string literals
Date
Msg-id 439D39CD.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Backslashes in string literals  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Backslashes in string literals
List pgsql-hackers
>>> On Sat, Dec 10, 2005 at  8:01 pm, in message
<200512110201.jBB21PE16562@candle.pha.pa.us>, Bruce Momjian
<pgman@candle.pha.pa.us> wrote: 
> Kevin Grittner wrote:
>> Since the
>> non- standard behavior is in the lexer, I couldn't see any
reasonable way
>> to base it on a runtime switch.  I'm curious what is intended here. 
Can
>> anyone give a one- paragraph explanation of how this configuration
option
>> will work?
> 
> Have you read our documentation?
>     http://www.postgresql.org/docs/8.1/static/sql- syntax.html#SQL-
SYNTAX- CONSTANTS
>     http://www.postgresql.org/docs/8.1/static/runtime- config-
compatible.html#RUNTI
> ME- CONFIG- COMPATIBLE- VERSION

Yes.

> Between those and the release notes, I don't know what additional
> information you want.  In the future you will set
> standard_conforming_strings to on and backslashes will be treated
> literally.

Perhaps my language was ambiguous.  I'm not curious about the intended
behavior from a user perspective, but what I might have missed in the
source code which would have allowed me to write my patch to better
comply with the documentation you cited.  Since the problem is in the
lexer, the only way I could see to implement it as a run-time
configuration option, rather than a compile-time option, would be to
duplicate the lexer and maintain two sets of rules in parallel.  I
generally try to avoid maintaining two parallel copies of code.  I'm
curious whether I missed some other programming approach.

-Kevin



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: default resource limits
Next
From: David Fetter
Date:
Subject: Re: psql patch: new host/port