Re: poll: CHECK TRIGGER?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: poll: CHECK TRIGGER?
Date: 2012-03-07 19:11:36
Message-ID: CAFj8pRD3jcO9=TBb3=A80z9V0nAM1bROFQNGXLH=2poeBTJv-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/3/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> More importantly, I do not agree with requiring the user to specify the
>>> language name --- that is, it should be check_function(procoid) and have
>>> that look up a language-specific checker.  Otherwise, scenarios like
>>> "check all my functions regardless of language" are too painful.
>>> There is value-added in providing that much infrastructure.
>
>> I might agree with you if we had more than one checker function, but
>> right now we are proposing to implement this for PL/pgsql and only
>> PL/pgsql.  It seems to me that we can add that when and if a second
>> checker function shows up, if it still seems like a good idea.
>
> That argument is just silly.  The only reason there's only one checker
> function is that that's all Pavel has bothered to write yet, and all
> that he's likely to write since (AFAICT) he doesn't care about the other
> PLs.  But other people do.  There is certainly value in being able to do
> checking of other languages, and if we don't set this up properly now,
> we're going to have problems with having to change the user-visible API
> later.
>
> I said from the beginning that I thought the most important part of this
> patch was getting the API for the language-specific validator functions
> right, and I remain of that opinion.  If we're going to blow that off
> then we should forget the patch entirely until we have time to do it
> right.
>

I believe so with some minimal support for other languages - tj
check_function, there will be other checker functions early. Preparing
plpgsql_check_function instead check_function save 10 lines of code,
and we will close door to other.

I am working on some minimalistic patch

Pavel

>                        regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Shulgin 2012-03-07 19:16:28 Re: WIP: URI connection string support for libpq
Previous Message Simon Riggs 2012-03-07 19:06:21 Re: RFC: Making TRUNCATE more "MVCC-safe"