From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | M <sitrash(at)email(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6301: extra space in psql variable expansion |
Date: | 2011-11-19 16:20:39 |
Message-ID: | 17805.1321719639@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
> On Fri, Nov 18, 2011 at 1:12 PM, M <sitrash(at)email(dot)com> wrote:
>> When psql expands a :variable into a string it appends a space to the
>> expansion string.
It doesn't actually do that, but rather splits the argument into two
arguments. \echo makes it look like there's spaces between arguments...
> I don't see the exact commit which fixed this, but I do see some fixes
> to psql's lexer done recently, such as
> 928311a463d480ca566e2905a369ac6aa0c3e210, so maybe this case got fixed
> as a nice side-effect.
I think the description of that commit addresses the point exactly:
... we considered an argument
completed as soon as we'd processed one backtick, variable
reference, or quoted substring. A string like 'FOO'BAR was thus
taken as two arguments not one, not exactly what one would
expect. In the new coding, an argument is considered terminated
only by unquoted whitespace or backslash.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-19 16:25:34 | Re: BUG #6301: extra space in psql variable expansion |
Previous Message | Tom Lane | 2011-11-19 15:34:28 | Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions |