Hello 2011/9/11 Tom Lane <t...@sss.pgh.pa.us>: > Andy Colson <a...@squeakycode.net> writes: >> [ Andy's dubious about adding plpgsql syntax to control this feature ] > > Yeah, that bothers me a lot too. >
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. And if I remember well, there was one tool that does it too, but a goal was different - they wanted a faster function execution in production usage - without "slower" first call. The overhead of check walker is minimal. >> One option I'd thought about, was to extended ANALYZE to support functions. > > That's actually quite a good idea, not least because the extra checking > happens only when you ask for it and not every time the function is > loaded into a new session. > > I'm not that happy with overloading the ANALYZE keyword to mean this > (especially not since there is already meaning attached to the syntax > "ANALYZE x(y)"). But we could certainly use some other name --- I'm > inclined to suggest CHECK: > > CHECK FUNCTION function_name(arglist); > I proposed a stored procedure "check_function(name, arglist)", but CHECK FUNCTION is ok for me too. Is easy implement it. Maybe there is issue - "CHECK" will be a keyword :( > People would want some sort of wild card capability; at the very least > "check all plpgsql functions owned by me". Not sure what that ought > to look like syntactically. I don't think. Now (when I looking around me) a owner of functions are some abstract role. It is terrible to maintain a system where database objects has a different roles. I can expect a request for check all functions from some schema or all functions related to some PL. > > It might also be a good idea to make sure there's room in the syntax to > specify different checking options. We already would have reason to > want "just do the existing style of validation check" versus this more > intensive check. And it's not hard to foresee other sorts of checking > in future. > +1 There is possible check of RAISE statement params and maybe similar. > Also, this would force us to invent PL-independent infrastructure for > doing the checking. I'm envisioning an additional argument to the > existing PL validator function that tells it what checking options to > use. > +1 yup. But there is query - need we a new special statement? cannot we enhance a CREATE OR REPLACE FUNCTION statement? Cannot we enhance of syntax or cannot we enhance of behave. or has sense to have two statements CREATE FUNCTION and CHECK FUNCTION? I see a sense. CHECK FUNCTION should be ??parametrized?? One idea - CHECK FUNCTION can have a own independent hooks on PL hooks. Resume: * We want to deep check plans when function is started * I like a CHECK FUNCTION statement - see a possibilities - but I am not sure if PL developers will like it too. It means start two statements - it just idea - what about CREATE OR REPLACE FUNCTION blabla() ... IMMUTABLE STRICT >>CHECK<< - so CREATE STATEMENT can optionally to call CHECK statement > regards, tom lane > there is still task - what with trigger's functions Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
