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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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