Re: Backslashes in string literals
Kevin Grittner wrote:
On Wed, Feb 1, 2006 at 10:50 am, in message
<200602011650.k11GoiU23147@candle.pha.pa.us>, Bruce Momjian
<pgman@candle.pha.pa.us> 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 to call libpq's pqSaveParameterStatus()
from
psql. Take a look for psql's session_username(). It is called
everytime the prompt is printed if the username is required. Onegreat
feature of using pqSaveParameterStatus() is that it reads server
packets
and keeps the tracked value updated for you without query overhead.
My attempt to do as you suggest isn't working. It behaves as though
the standard_strings() function I added to common.c is always returning
false. (If I comment out the reference the function, and the else
clause, I can get psql to work with the "on" state; otherwise, no joy.
The back end is working fine in all my tests.) I tried to mimic the
technique in the existing functions. Can you give me a clue where I'm
going wrong?
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 variable. Sorry I didn't know that detail before.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 43EB7F8E.EE98.0025.0@wicourts.gov
On Thu, Feb 9, 2006 at 10:31 pm, in message
<200602100431.k1A4VlY21635@candle.pha.pa.us>, Bruce Momjian
<pgman@candle.pha.pa.us> 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 variable. Sorry I didn't know that detail before.
Fantastic! I added that flag on my end, and everything I've tried is
working perfectly, except: I found that I didn't get my "expected" file
100% right with my hand-crafted attempt. You're probably already on
that, but just in case it might save you a few minutes -- attached is a
good patch for the "expected" file to go with the new regression test
script for strings.
-Kevin
Attachments:
strings.out.patchapplication/octet-stream; name=strings.out.patchDownload+87-4
Kevin Grittner wrote:
On Thu, Feb 9, 2006 at 10:31 pm, in message
<200602100431.k1A4VlY21635@candle.pha.pa.us>, Bruce Momjian
<pgman@candle.pha.pa.us> 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 madeto
that variable. Sorry I didn't know that detail before.
Fantastic! I added that flag on my end, and everything I've tried is
working perfectly, except: I found that I didn't get my "expected" file
100% right with my hand-crafted attempt. You're probably already on
that, but just in case it might save you a few minutes -- attached is a
good patch for the "expected" file to go with the new regression test
script for strings.
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
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> 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 expected file
once you've decided it's OK. The regression.diff file is inexact
because of the diff switches that are used.
If you need to update expected variants your machine doesn't generate,
make a fresh regular diff off the expected and actual, and apply that
to the other variants.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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.diffOh, that explains a few things ...
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?
If you need to update expected variants your machine doesn't generate,
make a fresh regular diff off the expected and actual, and apply that
to the other variants.
Ah, good point. I often forget about those.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> 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?
Not when the diff it's given to work from ignores spaces ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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?
Not when the diff it's given to work from ignores spaces ...
Ah, interesting. I had not realized that.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073This 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 big as that patch.)
-Kevin
On Sun, Feb 12, 2006 at 3:17 pm, in message
<200602122117.k1CLHuU22118@candle.pha.pa.us>, Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi- bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews
Show quoted text
and approves it.
Import Notes
Reply to msg id not found: 200602122117.k1CLHuU22118@candle.pha.pa.usReference msg id not found: 43EB7F8E.EE98.0025.0@wicourts.govReference msg id not found: 200602122117.k1CLHuU22118@candle.pha.pa.us | Resolved by subject fallback
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 hackers list
won't take a file as big as that patch.)
Oh, I was just going to add the GUC_REPORT when I applied the patch. I
put that email in the patch queue so I would not forget.
I you want, send a mega patch to the patches list,
pgsql-patches@postgresql.org. One large patch is usually safest to
apply.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073