Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-11-19 16:25:34
Subject: Re: BUG #6301: extra space in psql variable expansion
Previous:From: Tom LaneDate: 2011-11-19 15:34:28
Subject: Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group