2012/4/4 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > On 30.03.2012 12:36, Pavel Stehule wrote: >> >> 2012/3/28 Heikki Linnakangas<heikki.linnakan...@enterprisedb.com>: >>> >>> 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. >> >> >> It cannot be implemented in AST interpret. Without removing some >> requested functionality - fatal_errors. > > > I don't think I'm getting my point across by explaining, so here's a > modified version of the patch that does what I was trying to say. The > general pattern of the checker functions has been changed. Instead of > returning a boolean indicating error or no error, with checks for > fatal_errors scattered around them, the internal checker functions now > return nothing. Any errors are reported with ereport(), and there is a > PG_TRY/CATCH block in a couple of carefully chosen places: in check_stmt(), > so that if you get an error while checking a statement, you continue > checking on the next statement, and in check_assignment() which is now used > by check_expr() and a few other helper functions to basically check all > expressions and SQL statements. > > IMHO this makes the code much more readable, now that the control logic of > when to return and when to continue is largely gone. A lot of other cleanup > still needs to be done, I just wanted to demonstrate this ereport+try/catch > idea with this patch.
I checked your idea and it should to work. What other cleanup (without mentioned in previous mails) do you think? Regards Pavel > > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
