Re: [REVIEW] prepare plans of embedded sql on function start - Mailing list pgsql-hackers

Andy Colson <andy@squeakycode.net> writes:
> [ Andy's dubious about adding plpgsql syntax to control this feature ]

Yeah, that bothers me a lot too.

> 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);

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.

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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Thinking about inventing MemoryContextSetParent
Next
From: Marti Raudsepp
Date:
Subject: [WIP] Caching constant stable expressions per execution