Re: ToDo: plpgsql plugin for query and expression verification
От | Hitoshi Harada |
---|---|
Тема | Re: ToDo: plpgsql plugin for query and expression verification |
Дата | |
Msg-id | e08cc0401002160755i219127berbdd5cb66033a1d34@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ToDo: plpgsql plugin for query and expression verification (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
2010/2/16 Pavel Stehule <pavel.stehule@gmail.com>: > 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. Hmm, type mismatching can be checked by your suggestion, but that's it. The true answer to your original post might be "write unit test", isn't it? Regards, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: