Skip site navigation (1) Skip section navigation (2)

Re: [REVIEW] prepare plans of embedded sql on function start

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
Date: 2011-09-10 22:21:22
Message-ID: 23452.1315693282@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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
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

In response to

Responses

pgsql-hackers by date

Next:From: Marti RaudseppDate: 2011-09-10 22:27:17
Subject: [WIP] Caching constant stable expressions per execution
Previous:From: Tom LaneDate: 2011-09-10 22:03:23
Subject: Thinking about inventing MemoryContextSetParent

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group