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

Search Discussions

  • Tom Lane at Nov 1, 2008 at 6:03 pm

    Greg Stark 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 1, '08 at 12:17p
activeNov 1, '08 at 6:03p
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Greg Stark: 1 post Tom Lane: 1 post

People

Translate

site design / logo © 2021 Grokbase