2010/2/16 Hitoshi Harada <umi.tan...@gmail.com>: > 2010/2/16 Pavel Stehule <pavel.steh...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
