2011/9/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andy Colson <andy(at)squeakycode(dot)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.
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
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.
* 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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-09-11 05:21:00|
|Subject: Re: [REVIEW] prepare plans of embedded sql on function start |
|Previous:||From: Fujii Masao||Date: 2011-09-11 04:24:10|
|Subject: Re: pg_last_xact_insert_timestamp|