Re: poll: CHECK TRIGGER?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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-04-04 19:49:38
Message-ID: CAFj8pRDuzwdcCmJsbD=9+w=gRPKppzGNJpNJxsw4Barjj4=8RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/4/4 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> On 30.03.2012 12:36, 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.
>>
>>
>> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-04-04 20:00:07 Re: man pages for contrib programs
Previous Message Alvaro Herrera 2012-04-04 19:42:04 Re: parallel pg_dump