2010/2/16 Hitoshi Harada <umi.tanuki@gmail.com>:
> 2010/2/16 Pavel Stehule <pavel.stehule@gmail.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
>
