Обсуждение: Re: pgsql: Allow SQL-language functions to return the output of an
This isn't the same thing as allowing RETURNING inside subqueries, right? greg On 31 Oct 2008, at 07:37 PM, tgl@postgresql.org (Tom Lane) wrote: > Log Message: > ----------- > Allow SQL-language functions to return the output of an INSERT/ > UPDATE/DELETE > RETURNING clause, not just a SELECT as formerly. > > A side effect of this patch is that when a set-returning SQL > function is used > in a FROM clause, performance is improved because the output is > collected into > a tuplestore within the function, rather than using the less efficient > value-per-call mechanism. > > Modified Files: > -------------- > pgsql/doc/src/sgml: > xfunc.sgml (r1.132 -> r1.133) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/xfunc.sgml?r1=1.132&r2=1.133 > ) > pgsql/src/backend/executor: > execQual.c (r1.235 -> r1.236) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execQual.c?r1=1.235&r2=1.236 > ) > functions.c (r1.126 -> r1.127) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/functions.c?r1=1.126&r2=1.127 > ) > pgsql/src/backend/tcop: > dest.c (r1.72 -> r1.73) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/dest.c?r1=1.72&r2=1.73 > ) > pgsql/src/backend/utils/fmgr: > README (r1.15 -> r1.16) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README?r1=1.15&r2=1.16 > ) > pgsql/src/include/executor: > functions.h (r1.31 -> r1.32) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/functions.h?r1=1.31&r2=1.32 > ) > pgsql/src/include/nodes: > execnodes.h (r1.193 -> r1.194) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h?r1=1.193&r2=1.194 > ) > pgsql/src/include/tcop: > dest.h (r1.54 -> r1.55) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/tcop/dest.h?r1=1.54&r2=1.55 > ) > pgsql/src/test/regress/expected: > rangefuncs.out (r1.19 -> r1.20) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/rangefuncs.out?r1=1.19&r2=1.20 > ) > pgsql/src/test/regress/output: > create_function_1.source (r1.33 -> r1.34) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/output/create_function_1.source?r1=1.33&r2=1.34 > ) > pgsql/src/test/regress/sql: > rangefuncs.sql (r1.8 -> r1.9) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/rangefuncs.sql?r1=1.8&r2=1.9 > ) > > -- > Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org > ) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-committers
Greg Stark <greg.stark@enterprisedb.com> writes: > This isn't the same thing as allowing RETURNING inside subqueries, > right? Right. You could fairly easily get that now by wrapping your RETURNING query into a SQL function ... but I'm not sure that we want to advertise that heavily, because the question of just when the subquery gets executed still isn't resolved with any degree of precision. It might be that the current behavior is fine, but I'm not feeling we should swear to it. regards, tom lane