PERFORM effects FOUND patch (Was: I must be blind...) - Mailing list pgsql-general
From | Nigel J. Andrews |
---|---|
Subject | PERFORM effects FOUND patch (Was: I must be blind...) |
Date | |
Msg-id | Pine.LNX.4.21.0206151611350.2308-100000@ponder.fairway2k.co.uk Whole thread Raw |
In response to | Re: I must be blind... (Alvaro Herrera <alvherre@atentus.com>) |
Responses |
Re: PERFORM effects FOUND patch (Was: I must be blind...)
|
List | pgsql-general |
On Fri, 14 Jun 2002, Alvaro Herrera wrote: > Tom Lane dijo: > > > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > > > However, because PERFORM discards the results of a query it is only > > > useful for side effects of the query. > > > Okay. I guess the next question is whether PERFORM *should* be setting > > FOUND. Seems like it might be a reasonable thing to do. > > Well, actually FOUND _is_ a side effect of PERFORM, IMHO. I also tried > to do the very same thing, and also had to use the dummy variable, which > seems like a waste to me. > > I do not know anything about Oracle's PERFORM, though a quick search on > Google shows nothing relevant. I know nothing of Oracle's use of PERFORM either. Indeed I have looked in 4 Oracle books 'Oracle 8i The Complete Reference', 'Oracle8i DBA Bible', 'Oracle PL/SQL Language Pocket Reference' and one on PL/SQL Builtins (on the off chance), and couldn't find any reference to PERFORM. I even scanned, by eye, every page of the PL/SQL reference and saw nothing. On that basis I've included a patch that sets FOUND to true if a PERFORM <query> 'processes' a row. From looking at other routines in pl_exec.c I believe that I have used the correct test. As FOUND isn't testing as true after a PERFORM at the moment I also presume there is no need for an explicit set to false. I have tested this in 7.3dev with the regression tests and the case that caused me to come across this situation and no errors occured. The patch is at the bottom of this message. I don't know if this should be applied though. There seems to be one vote for it, at least, but there is a question over what other systems do in this situation. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants Index: src/pl/plpgsql/src/pl_exec.c =================================================================== RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v retrieving revision 1.55 diff -c -r1.55 pl_exec.c *** src/pl/plpgsql/src/pl_exec.c 2002/03/25 07:41:10 1.55 --- src/pl/plpgsql/src/pl_exec.c 2002/06/15 15:10:38 *************** *** 981,989 **** if (expr->plan == NULL) exec_prepare_plan(estate, expr); ! rc = exec_run_select(estate, expr, 0, NULL); if (rc != SPI_OK_SELECT) elog(ERROR, "query \"%s\" didn't return data", expr->query); exec_eval_cleanup(estate); } --- 981,992 ---- if (expr->plan == NULL) exec_prepare_plan(estate, expr); ! rc = exec_run_select(estate, expr, 1, NULL); if (rc != SPI_OK_SELECT) elog(ERROR, "query \"%s\" didn't return data", expr->query); + + if (estate->eval_processed != 0) + exec_set_found(estate, true); exec_eval_cleanup(estate); }
pgsql-general by date: