|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andy Colson <andy(at)squeakycode(dot)net>|
|Cc:||pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pavel(dot)stehule(at)gmail(dot)com|
|Subject:||Re: [REVIEW] prepare plans of embedded sql on function start|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
> 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
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
regards, tom lane
|Next Message||Marti Raudsepp||2011-09-10 22:27:17||[WIP] Caching constant stable expressions per execution|
|Previous Message||Tom Lane||2011-09-10 22:03:23||Thinking about inventing MemoryContextSetParent|