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
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 |