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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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-10 22:32:42
Message-ID: AANLkTimGbawPQAGrsVOkCNi2XDM8fsuUm1f8KJy45lnv@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, May 5, 2010 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I notIced this when working on Pavel's patch to make :'foo' and :"foo"
do interpolation with literal/identifier quoting, and thought that it
would benefit from some refactoring, but didn't want to bother with it
at the time. It's seems like kind of a pain for the amount of benefit
we'd likely to get out of it, but I think we'd probably be happier in
the long run.

http://en.wikipedia.org/wiki/Frog_boiling

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Takahiro Itagaki 2010-05-11 04:59:00 Re: [HACKERS] "SET search_path" clause ignored during function creation
Previous Message Tom Lane 2010-05-10 17:56:54 Re: "SET search_path" clause ignored during function creation