From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Petr Jelinek <pjmodos(at)pjmodos(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql_check_function - rebase for 9.3 |
Date: | 2013-03-03 14:53:41 |
Message-ID: | CAFj8pRBHgk5f8ZjvN3c1VdfJ-z8_xWUf6jzF5g84hEos67FUBw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)stehule(at)gmail(dot)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(dot)stehule(at)gmail(dot)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(at)chesnok(dot)com>:
>>> Hi!
>>>
>>> On Tue, Jun 26, 2012 at 1:19 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-03 15:17:26 | Re: [v9.3] writable foreign tables |
Previous Message | Craig Ringer | 2013-03-03 14:53:15 | Re: WIP: store additional info in GIN index |