From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ToDo: plpgsql plugin for query and expression verification |
Date: | 2010-02-16 13:44:18 |
Message-ID: | 162867791002160544k28e53869g360f7b93034740b9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/2/16 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
> 2010/2/16 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> I think, so these problem have to be identified in compile stage - but
>> it can be too strict for all (and can slow down production) - it is
>> reason for plugin.
>>
>> What do you think about this idea?
>
> How do you identify them? Running function body cannot be applied if
> the function is volatile. Also, I don't see how do you choose function
> argument values even in immutable cases.
It is issue only for dynamic sql and polymorphic functions. But for
all others we can do full check in validation stage. I thinking about
similar tool to lint - just for plpgsql function. It cannot detect all
bugs, but it can diagnose 99% of possible issues.
I don't would to execute function - it is useless because you need
good UI for execution all path. My idea is different. gram.y has
check_sql_expr rutine. This is used for parser checking every static
SQL fragment in plpgsql function. With some hook we can do full plan
generation instead.
Regards
Pavel Stehule
>
> Regards,
>
> --
> Hitoshi Harada
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-02-16 14:04:11 | Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while |
Previous Message | Andrew Dunstan | 2010-02-16 13:11:15 | Re: OpenVMS? |