Re: [REVIEW] prepare plans of embedded sql on function start
От | Pavel Stehule |
---|---|
Тема | Re: [REVIEW] prepare plans of embedded sql on function start |
Дата | |
Msg-id | CAFj8pRBTKshYKy-Z3=HNW-OMAq+1_CCULNi78-7X47qx=Y=oEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [REVIEW] prepare plans of embedded sql on function start (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [REVIEW] prepare plans of embedded sql on function start
Re: [REVIEW] prepare plans of embedded sql on function start |
Список | 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@sss.pgh.pa.us>: > 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 по дате отправления: