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

Re: BUG #5448: psql \set does not terminate if variable is referenced recursively

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Francis" <fmarkham(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5448: psql \set does not terminate if variable is referenced recursively
Date: 2010-05-05 17:50:58
Message-ID: 6332.1273081858@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could print a message and treat the inner
>> expansion as empty --- is that good enough?
 
> If there's any way to throw an error, that seems better.  I can
> imagine someone getting confused by silent failure here.  On the
> other hand, since this probably doesn't happen very often, maybe
> it's not worth the effort.  I could even see an argument for just
> testing for Ctrl+C before each expansion and otherwise leaving it as
> is.

The problem is there's no real support inside psql for "throwing an
error" --- we have to unwind all the state manually.  In particular,
what this problem requires is backing out the stack of flex buffers
representing pending variable expansions.  So I think we need to add
an explicit recursion test and suppress further expansion of the
variable when we see it, but there's no very simple way to just abandon
the current command altogether.

We can definitely print a message though, and I agree that just silently
suppressing recursion would be confusing.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2010-05-05 17:54:21
Subject: Re: BUG #5448: psql \set does not terminate if variable is referenced recursively
Previous:From: Kevin GrittnerDate: 2010-05-05 17:24:36
Subject: Re: BUG #5448: psql \set does not terminate if variable is referenced recursively

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