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 по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Command Triggers patch v18
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: pgxs and bison, flex