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-29 16:07:02
Message-ID: 4F7488A6.8030900@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28.03.2012 23:54, Pavel Stehule wrote:
> 2012/3/28 Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-29 16:07:19 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous Message Thom Brown 2012-03-29 15:49:44 Re: Command Triggers patch v18