2012/3/29 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > On 28.03.2012 23:54, 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. >> >> >> This is not possible, when we would to enable "fatal_errors = false" >> checking. I can do subtransaction in prepare_expr, because it is the >> most deep level, but I cannot to use it elsewhere, because I cannot >> handle exception and continue with other parts of statement. > > > Well, you can continue on the next statement. That's almost as good. In > practice, if there's one error in a statement, it seems unlikely that you > would correctly diagnose other errors on the same line. They're more likely > to be fallout of the same mistake.
no, for example, it means, if I found error in "if_then" statements, still I would to check "else" statements. 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
