Hello
I thinking about more restrictive query and expression checking than
now. Used parser checking isn't enough - so some possible bugs can be
detected in production stage. Other problem is using any expression
as SELECT expr. The request on validation can be different and it is
probably for
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
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?
Pavel Stehule pavel.steh...@gmail.com writes:
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
2010/2/16 Pavel Stehule pavel.steh...@gmail.com:
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
2010/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
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
