| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: Controlling changes in plpgsql variable resolution |
| Date: | 2009-10-19 19:14:58 |
| Message-ID: | 9929.1255979698@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Where exactly would you put the modifier, and why is that better than
> the existing #option convention?
BTW, it occurs to me that since that's undocumented, not everyone might
know what I'm talking about. There's some code in plpgsql that allows
you to write
#option dump
at the very beginning of a plpgsql function body, and get a dump of the
plpgsql syntax tree. Since this was never intended for anything except
low-level debugging, it never got documented --- but the obvious
intention was that other sorts of options might come along later.
Now we have a case where a per-function option seems like just the
ticket.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-10-19 19:23:39 | Re: Controlling changes in plpgsql variable resolution |
| Previous Message | David E. Wheeler | 2009-10-19 19:13:38 | Re: Controlling changes in plpgsql variable resolution |