Pavel Stehule <pavel.steh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers