Re: poll: CHECK TRIGGER?

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: poll: CHECK TRIGGER?
Date: 2012-03-09 20:09:47
Message-ID: 1331323787.23681.6.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On tor, 2012-03-08 at 23:15 +0100, Pavel Stehule wrote:
> But you propose some little bit different than is current plpgsql
> checker and current design.

Is it? Why? It looks like exactly the same thing, except that the
interfaces you propose are tightly geared toward checking SQL-like
languages, which looks like a mistake to me.

> It's not bad, but it is some different and it is not useful for
> plpgsql - external stored procedures are different, than SQL
> procedures and probably you will check different issues.
>
> I don't think so multiple checkers and external checkers are necessary
> - if some can living outside, then it should to live outside. Internal
> checker can be one for PL language. It is parametrized - so you can
> control goals of checking.

What would be the qualifications for being an internal or an external
checker? Why couldn't your plpgsql checker be an external checker?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-09 20:10:28 Re: RFC: Making TRUNCATE more "MVCC-safe"
Previous Message Yeb Havinga 2012-03-09 20:09:43 Re: [v9.2] Add GUC sepgsql.client_label