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
create or replace function foo(a varchar, b varchar)
returns varchar as $$
a = current_date; -- result type is different then target type
return a || b || c; -- simple expression has unknown symbol
$$ language plpgsql;
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?
pgsql-hackers by date
|Next:||From: Boszormenyi Zoltan||Date: 2010-02-16 08:08:21|
|Subject: Re: [GENERAL] libecpg versions and libecpg_compat|
|Previous:||From: Greg Smith||Date: 2010-02-16 07:41:40|
|Subject: Re: psycopg2 license changed|