Kevin Grittner wrote:
> This patch doesn't leave the standard_conforming_strings entry in guc.c
> with the GUC_REPORT flag, which it needs for psql to work right. Should
> I submit one last patch with this fix and the proper "expected"
> regression file? If so, where should I send it? (The hacke
This patch doesn't leave the standard_conforming_strings entry in guc.c
with the GUC_REPORT flag, which it needs for psql to work right. Should
I submit one last patch with this fix and the proper "expected"
regression file? If so, where should I send it? (The hackers list
won't take a file as b
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> It's much better to just copy the result file over the expected file
> >> once you've decided it's OK. The regression.diff file is inexact
> >> because of the diff switches that are used.
>
> > I am confused. patch dosen't make an
Bruce Momjian writes:
> Tom Lane wrote:
>> It's much better to just copy the result file over the expected file
>> once you've decided it's OK. The regression.diff file is inexact
>> because of the diff switches that are used.
> I am confused. patch dosen't make an indentical file? Example?
N
Tom Lane wrote:
> Bruce Momjian writes:
> > Oh, what I normally do is to look at regression.diff, and if that looks
> > OK, I just apply it to the expected file like this:
>
> > cd expected
> > patch < ../regression.diff
>
> Oh, that explains a few things ...
>
> It's much better to jus
Bruce Momjian writes:
> Oh, what I normally do is to look at regression.diff, and if that looks
> OK, I just apply it to the expected file like this:
> cd expected
> patch < ../regression.diff
Oh, that explains a few things ...
It's much better to just copy the result file over the
Kevin Grittner wrote:
> >>> On Thu, Feb 9, 2006 at 10:31 pm, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> wrote:
> >
> > OK, I got it working. The fix is to add GUC_REPORT to guc.c for
> > standard_conforming_strings. See the same flag on
> > session_authorization. That will cause libpq
>>> On Thu, Feb 9, 2006 at 10:31 pm, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
>
> OK, I got it working. The fix is to add GUC_REPORT to guc.c for
> standard_conforming_strings. See the same flag on
> session_authorization. That will cause libpq to see any changes made
to
> that va
Kevin Grittner wrote:
> >>> On Wed, Feb 1, 2006 at 10:50 am, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> wrote:
> >>
> >> (1) I couldn't figure out the best way to obtain a value for
> >> standard_conforming_strings in the psql version of the scanner.
> >
> > The proper way to do (1) is
Kevin Grittner wrote:
> >> to generalize it. As far as I can tell from some testing today,
> >> everything works fine issuing statements through a connection, but
> psql
> >> isn't settled down.
> >
> > Sounds like you made great progress!
>
> Thanks. It was actually pretty easy once I took the
>>> On Wed, Feb 1, 2006 at 10:50 am, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
> Kevin Grittner wrote:
>> We found a bug in the code from my first patch. Since it was a low
>> frequency, non- destructive type of problem for us, I was able to
take my
>> time and look over the task a li
Kevin Grittner wrote:
> We found a bug in the code from my first patch. Since it was a low
> frequency, non-destructive type of problem for us, I was able to take my
> time and look over the task a little more closely. Attached is a patch
> which should come close to implementing the TODO. In pa
>>> On Wed, Jan 25, 2006 at 4:46 pm, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
>
> (2) There should probably be some tests added to exercise these
> options.
Attached is a patch to address this one. Note that until psql is
fixed, this test will fail. I manua
We found a bug in the code from my first patch. Since it was a low
frequency, non-destructive type of problem for us, I was able to take my
time and look over the task a little more closely. Attached is a patch
which should come close to implementing the TODO. In particular, it is
now implemente
Kevin Grittner wrote:
> > 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 i
>>> On Sat, Dec 10, 2005 at 8:01 pm, in message
<[EMAIL PROTECTED]>, Bruce Momjian
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
Kevin Grittner wrote:
> >>> On Fri, Dec 9, 2005 at 11:24 am, in message
> <[EMAIL PROTECTED]>, Peter Eisentraut
> <[EMAIL PROTECTED]> wrote:
>
> > Kevin Grittner wrote:
> >> direction PostgreSQL is headed is to drop the nonstandard escapes,
> >> unless an extended literal is explicitly used. I've
>>> On Fri, Dec 9, 2005 at 11:24 am, in message
<[EMAIL PROTECTED]>, Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> direction PostgreSQL is headed is to drop the nonstandard escapes,
>> unless an extended literal is explicitly used. I've attached a
patch
>> which supports
Peter Eisentraut wrote:
> Kevin Grittner wrote:
> > direction PostgreSQL is headed is to drop the nonstandard escapes,
> > unless an extended literal is explicitly used. I've attached a patch
> > which supports this as a configure option, using a
> > --enable-standard-strings switch.
>
> There is
Kevin Grittner wrote:
> direction PostgreSQL is headed is to drop the nonstandard escapes,
> unless an extended literal is explicitly used. I've attached a patch
> which supports this as a configure option, using a
> --enable-standard-strings switch.
There is already a run-time configuration opti
I think we we will be turning on escape_string_warning in 8.2 and allow
standard_conforming_strings to be optionally turned on in that releaes.
I will keep the patch for us in completing that item.
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_h
I've just been bitten by the "backslash in string literals" issue. I
have reviewed the mailing lists and the TODO list. I see that the
direction PostgreSQL is headed is to drop the nonstandard escapes,
unless an extended literal is explicitly used. I've attached a patch
which supports this as a
22 matches
Mail list logo
