Prev: psql tab-completion for new syntax
Next: [COMMITTERS] pgsql: Clean up package namespace use and use of Safe in plperl.
From: Pavel Stehule on 16 Feb 2010 03:05 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 more advanced users - so it could be wrapped to some plugin. So users can exactly set an level for checking that is the best for they. postgres=# set check_function_bodies to on;SET postgres=# create or replace function foo(a varchar, b varchar) returns varchar as $$ begin a = current_date; -- result type is different then target type return a || b || c; -- simple expression has unknown symbol end; $$ language plpgsql; CREATE FUNCTION 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? Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |