From: | "Brendan Jurd" <direvus(at)gmail(dot)com> |
---|---|
To: | "Neil Conway" <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FOUND with EXECUTE |
Date: | 2007-10-16 02:41:33 |
Message-ID: | 37ed240d0710151941l7f18a13dm211e8a9b9672f75f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/16/07, Neil Conway <neilc(at)samurai(dot)com> wrote:
> See prior discussion:
>
> http://archives.postgresql.org/pgsql-bugs/2004-10/msg00001.php
Thanks for the link. I did search the archives but unfortunately
terms like 'found' and 'execute' generate a lot of unwanted matches =)
>
> It would be easy enough to have EXECUTE modify FOUND, and that might
> well be worth doing. Adding an "EVAL" concept would also be useful,
> though, and would avoid changing EXECUTE's behavior in a way that might
> break client apps.
Hm, it seems the only thing that would be broken is a function which
runs an ordinary statement, and then waits until *after* doing an
EXECUTE to check the value of FOUND. It's tough to imagine somebody
actually relying on this behaviour, and perhaps it's fair to say that
failure to check FOUND immediately after the statement you're
interested in is bad coding practice?
Regards,
BJ
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-10-16 03:28:06 | Re: 8.3 full text search docs |
Previous Message | Tom Lane | 2007-10-16 01:48:42 | Re: UTF8 on Debian |