Re: plpgsql_check_function - rebase for 9.3 - Mailing list pgsql-hackers

Hello

I though about any possibility how to reduce a size of this patch.

I see a one solution - if we would not support a detection of multiple
errors - it stops on first error, we can push this code to compilation
stage.

a plpgsql_validator can be overloaded by function

plpgsql_validator(oid, reloid, level)

reloid - is requested by triggers - it is related class oid
level - it is level of checking

0 - same as current implementation - check only syntax errors
1 - stop on first object error - no table, no field, no expected data type
2 - stop on first performance issue - implicit casting identification
(should be removed or moved to next releases)

This proposal reduces functionality proposed for
plpgsql_check_function - but basic functionality is there.

It has not a impact on performance and it allow check all paths in
compile time.

It will not change behave of current CREATE OR REPLACE function -
there is not a problem with back compatibility

It is good for you?

I can have this modification to end of this week.

Regards

Pavel



2012/11/28 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> a some updated version
>
> * possibility to raise (and filter) performance warnings - detects IO castings
> * detects assign composite value to scalar variable
>
> Regards
>
> Pavel Stehule
>
> 2012/11/27 Pavel Stehule <pavel.stehule@gmail.com>:
>> Hello
>>
>> I am sending a updated version - now it is prepared for event triggers
>> and it is little bit more robust
>>
>> I run pgindent, but I have no experience with it, so I am not sure about success
>>
>> Regards
>>
>> Pavel Stehule
>>
>>
>> 2012/10/7 Selena Deckelmann <selena@chesnok.com>:
>>> Hi!
>>>
>>> On Tue, Jun 26, 2012 at 1:19 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>
>>>> I am sending lightly refreshed patch for checking plpgsql functions..
>>>>
>>>> I checked different implementation, but without success: a) enhancing
>>>> of SPI to some fake mode can has negative impact on application, and
>>>> patch was not clear, b) generic plpgsql walker doesn't save lines too.
>>>>
>>>> I invite any ideas how to improve this patch
>>>
>>> I reviewed this and did a clean up for bitrot and a little whitespace.
>>> In particular, it needed to learn a little about event triggers.
>>>
>>> This patch is a follow on from an earlier review thread I found:
>>> http://archives.postgresql.org/message-id/D960CB61B694CF459DCFB4B0128514C2072DF447@exadv11.host.magwien.gv.at
>>>
>>> I dug through that thread a bit, and I believe issues raised by
>>> Laurenz, Petr and Alvaro were resolved by Pavel over time.
>>>
>>> All tests pass, and after a read-through, the code seems fine.
>>>
>>> This also represents my inaugural use of pg_bsd_indent. I ran it on
>>> pl_check.c - which made things mostly better. Happy to try and fix it
>>> up more if someone can explain to me what (if anything) I did
>>> incorrectly when using it.
>>>
>>> -selena
>>>
>>> --
>>> http://chesnok.com