Re: review: CHECK FUNCTION statement
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2011-12-13T16:55:40Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add const qualifiers to node inspection functions
- d5f23af6bfbc 9.2.0 cited
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