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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] prepare plans of embedded sql on function start
Date: 2011-09-12 09:14:13
Message-ID: CAFj8pRBTKshYKy-Z3=HNW-OMAq+1_CCULNi78-7X47qx=Y=oEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

I started work on proposed check statement option and there are a few questions?

what is sense of this statement for others PL? When we solve a mainly
PL/pgSQL issue, has sense to implement new statement? Isn't a some
problem in our CREATE FUNCTION design? A separation to two steps
should has a little bit strange behave - we cannot to check a function
before their registration (we can, but we should to do a some game
with names) - there is necessary some a conditional CREATE FUNCTION
statement - some like "CREATE CHECKED FUNCTION " or CHECK FUNCTION
with function body.

comments?

Regards

Pavel Stehule

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.
>
>> 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2011-09-12 09:23:26 Re: Alpha 1 for 9.2
Previous Message Marko Tiikkaja 2011-09-12 09:12:03 Re: EXPLAIN and nfiltered, take two