From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: review: CHECK FUNCTION statement |
Date: | 2011-12-13 16:55:40 |
Message-ID: | CAFj8pRAWj0rc=t7i3RxV3ipNc9b1kL+fvbdf9EJ32-Hmyt5qFA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/12/13 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2011/12/13 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Tachoires | 2011-12-13 17:02:28 | Re: patch : Allow toast tables to be moved to a different tablespace |
Previous Message | Robert Haas | 2011-12-13 16:54:09 | Re: libpq: PQcmdStatus, PQcmdTuples signatures can be painlessly improved |