| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Some notes about Param handling with "Oracle style" plpgsql variables |
| Date: | 2009-11-02 17:42:04 |
| Message-ID: | 603c8f070911020942k555a970btd03fa02502deb6c3@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Another interesting property
> of this approach is that it'd fix the longstanding user complaint
> that constructions like
> if (TG_OP = 'INSERT' and NEW.foo = 'bar') ...
> fail prematurely. The executor would never demand the value
> of NEW.foo, and thus not fail, if TG_OP isn't INSERT.
I don't really know enough to comment on the best way to go about this
project overall, but fixing this would be incredibly nice, if it can
be done without too much damage.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2009-11-02 17:44:23 | Re: operator exclusion constraints |
| Previous Message | Alvaro Herrera | 2009-11-02 17:40:16 | Re: per-tablespace random_page_cost/seq_page_cost |