Re: BUG #6301: extra space in psql variable expansion

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

In response to

Browse pgsql-bugs by date

  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