Thread: pgsql/ oc/src/sgml/func.sgml oc/src/sgml/relea ...

CVSROOT:    /cvsroot
Module name:    pgsql
Changes by:    petere@postgresql.org    02/05/18 09:48:01

Modified files:
    doc/src/sgml   : func.sgml release.sgml
    doc/src/sgml/ref: create_function.sgml
    src/backend/catalog: pg_aggregate.c pg_proc.c
    src/backend/commands: functioncmds.c
    src/backend/utils/adt: sets.c
    src/backend/utils/fmgr: fmgr.c
    src/bin/pg_dump: pg_dump.c
    src/include/catalog: catversion.h pg_attribute.h pg_proc.h
    src/test/regress/expected: opr_sanity.out privileges.out
    src/test/regress/sql: opr_sanity.sql privileges.sql

Log message:
    Allow functions to be executed with the privileges of the function owner.
    I took the opportunity to remove the pg_proc.proistrusted field.

petere@postgresql.org (Peter Eisentraut - PostgreSQL) writes:
>     Allow functions to be executed with the privileges of the function owner.

Hmm.  Have you tried this with recursive plpgsql functions?  I have a
feeling that that little hack of replacing the flinfo link isn't gonna
work well in plpgsql, because of its caching of query plans.

Of course this is not so much the fault of your patch as it is of the
brain-dead notion of keeping runtime function caches in plan trees.
Maybe it's time to bite the bullet and do something about that.

            regards, tom lane

Tom Lane writes:

> Hmm.  Have you tried this with recursive plpgsql functions?  I have a
> feeling that that little hack of replacing the flinfo link isn't gonna
> work well in plpgsql, because of its caching of query plans.

I don't understand what specific problem you are referring to.  As long as
each function is only caching its own query plans in its own fn_extra area
then things shouldn't work differently from before.

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Hmm.  Have you tried this with recursive plpgsql functions?  I have a
>> feeling that that little hack of replacing the flinfo link isn't gonna
>> work well in plpgsql, because of its caching of query plans.

> I don't understand what specific problem you are referring to.

After further thought I believe that the problem cannot occur until we
have plpgsql functions that can return sets (and even then it could be
worked around if exec_eval_simple_expr isn't used for functions
returning sets, which it probably couldn't be anyway).
ExecMakeFunctionResult only keeps call state in the plan tree for
set-valued functions, so the recursive re-use of the plan tree doesn't
matter otherwise.

Just chalk it up as another bit of messiness that we need to fix
someday.

            regards, tom lane