Re: poll: CHECK TRIGGER?
От | Pavel Stehule |
---|---|
Тема | Re: poll: CHECK TRIGGER? |
Дата | |
Msg-id | CAFj8pRAAYaOCyvwWjTEdmXak+A_qMHMg9OFNu_yZJ2F5jNyUmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: poll: CHECK TRIGGER? (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
2012/3/29 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>: > On 28.03.2012 23:54, Pavel Stehule wrote: >> >> 2012/3/28 Heikki Linnakangas<heikki.linnakangas@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
В списке pgsql-hackers по дате отправления: