Re: poll: CHECK TRIGGER?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Petr Jelinek <pjmodos(at)pjmodos(dot)net>
Subject: Re: poll: CHECK TRIGGER?
Date: 2012-03-28 09:49:59
Message-ID: 4F72DEC7.5000907@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ok, seems that the API issue is settled, so I'm now looking at the code
actually doing the checking. My first impression is that this is a lot
of code. Can we simplify it?

Since this is deeply integrated into the PL/pgSQL interpreter, I was
expecting that this would run through the normal interpreter, in a
special mode that skips all the actual execution of queries, and
shortcuts all loops and other control statements so that all code is
executed only once. That would mean sprinkling some "if (check_only)"
code into the normal exec_* functions. I'm not sure how invasive that
would be, but it's worth considering. I think you would be able to more
easily catch more errors that way, and the check code would stay better
in sync with the execution code.

Another thought is that check_stmt() and all its subroutines are very
similar to the plpgsql_dumptree() code. Would it make sense to merge
those? You could have an output mode, in addition to the xml and
plain-text formats, that would just dump the whole tree like
plpgsql_dumptree() does.

In prepare_expr(), you use a subtransaction to catch any ERRORs that
happen during parsing the expression. That's a good idea, and I think
many of the check_* functions could be greatly simplified by adopting a
similar approach. Just ereport() any errors you find, and catch them at
the appropriate level, appending the error to the output string. Your
current approach of returning true/false depending on whether there was
any errors seems tedious.

If you create a function with an invalid body (ie. set
check_function_bodies=off; create function ... $$ bogus $$;) ,
plpgsql_check_function() still throws an error. It's understandable that
it cannot do in-depth analysis if the function cannot be parsed, but I
would expect the syntax error to be returned as a return value like
other errors that it complains about, not thrown as a hard ERROR. That
would make it more useful to bulk-check all functions in a database with
something like "select plpgsql_check_function(oid) from pg_class". As it
is, the checking stops at the first invalid function with an error.

PS. I think plpgsql_check_function() belongs in pl_handler.c

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anssi Kääriäinen 2012-03-28 10:55:06 Feature proposal: list role members in psql
Previous Message Peter Geoghegan 2012-03-28 09:47:49 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)