Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
>> statements for language SQL with a function body that conforms to the
>> SQL standard and is portable to other implementations.
> With what other implementations is it compatible?
Yeah ... I'm sort of wondering exactly what this really accomplishes.
I think "portability" is a red herring unfortunately.
Tracking the dependencies of the function body sounds nice at first
glance, so it might be a feature. But given our experiences with having
to use check_function_bodies = off to not have impossible dependency loops
in dump/restore, I rather wonder whether it'll be a net loss in practice.
IIUC, this implementation is flat out incapable of doing the equivalent of
check_function_bodies = off, and that sounds like trouble.
> Hmm, this all seems like a pretty big semantic change. IIUC, right
> now, a SQL function can only contain one statement,
Not true, you can have more. However, it's nonetheless an enormous
semantic change, if only because the CREATE FUNCTION-time search_path
is now relevant instead of the execution-time path. That *will*
break use-cases I've heard of, where the same function is applied
to different tables by adjusting the path. It'd certainly be useful
from some perspectives (eg better security), but it's ... different.
Replicating the creation-time search path will be a big headache for
pg_dump, I bet.
> But it almost seems like you are
> inventing a whole new PL....
Yes. Having this replace the existing SQL PL would be a disaster,
because there are use-cases this simply can't meet (even assuming
that we can fix the polymorphism problem, which seems a bit unlikely).
We'd need to treat it as a new PL type.
Perhaps this is useful enough to justify all the work involved,
but I'm not sure.
regards, tom lane