Re: [REVIEW] prepare plans of embedded sql on function start

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I like to discussion about syntax - a name "prepare_plans" and
> following list is just one (for me - practical) shot. I am sure so
> preparing all plans on function start is one functionality what we
> want - because it can to do early warnings when some in environments
> is not well.

I don't think it *is* functionality that we want. From a performance
standpoint it's certainly not a win: there is no savings from preparing
all the plans at the same time, and you can lose if there are code paths
that are never executed. The only argument for doing it is more
extensive checking.

And on the checking front, I like Andy's idea better than the original.
There is not value in repeating a checking effort in every single
process when nothing is changing. Furthermore, because of the problem
of the checks breaking functions that contain DDL, you have to have a
way of disabling it and you have to worry about setting up permission
mechanisms to restrict who can break whose functions, something that
will never work very smoothly IMO. (Certainly, having to be superuser
to enable checking is not a point in favor of your design.) Pushing the
checking out as a separately invokable operation neatly bypasses both of
those problems. Right offhand I'm not sure we need any permission
restrictions at all on a CHECK operation, but at the worst, permission
to call the function ought to be enough.

> there is still task - what with trigger's functions

"CHECK TRIGGER name ON tablename" could be syntactic sugar for calling
the validator on the trigger's function and passing it sufficient
information to set up the trigger arguments properly.

regards, tom lane