Re: review: CHECK FUNCTION statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: review: CHECK FUNCTION statement
Date
Msg-id CAFj8pRAWj0rc=t7i3RxV3ipNc9b1kL+fvbdf9EJ32-Hmyt5qFA@mail.gmail.com
Whole thread Raw
In response to Re: review: CHECK FUNCTION statement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2011/12/13 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/12/13 Albe Laurenz <laurenz.albe@wien.gv.at>:
>>> Either that, or couldn't you pass an option List as data type "internal"?
>
>> this is question - internal is most simply solution, but then we
>> cannot to call check function directly
>
> Yeah, one of the proposals for allowing people to specify complicated
> conditions about what to check was to tell them to do
>        select checker(oid) from pg_proc where any-random-condition;

> If the checker isn't user-callable then we lose that escape hatch, and
> the only selection conditions that will ever be possible are the ones
> we take the trouble to shoehorn into the CHECK FUNCTION statement.
> Doesn't seem like a good thing to me.

yes, it is reason why I thinking just about string array.

I have not idea about other PL, but options for plpgsql can be one
word and checker function can simply parse two or more words options.

Now I would to implement flags "quite" - ignore NOTIFY messages and
"fatal_errors" to stop on first error.

Regards

Pavel


>
>                        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: libpq: PQcmdStatus, PQcmdTuples signatures can be painlessly improved
Next
From: Julien Tachoires
Date:
Subject: Re: patch : Allow toast tables to be moved to a different tablespace