Re: review: CHECK FUNCTION statement
Petr Jelinek <pjmodos@pjmodos.net>
From: Petr Jelínek <pjmodos@pjmodos.net>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Greg Smith <greg@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Albe Laurenz <laurenz.albe@wien.gv.at>
Date: 2012-03-03T13:26:04Z
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
On 03/03/2012 02:24 AM, Alvaro Herrera wrote: > question: how attached you are to the current return format for CHECK > FUNCTION? > > check function f1(); > CHECK FUNCTION > ------------------------------------------------------------- > In function: 'f1()' > error:42804:5:assignment:subscripted object is not an array > (2 rows) > > It seems to me that it'd be trivial to make it look like this instead: > > check function f1(); > function | lineno | statement | sqlstate | message | detail | hint | level | position | query > ---------+--------+------------+----------+------------------------------------+--------+------+-------+----------+------- > f1() | 5 | assignment | 42804 | subscripted object is not an array | | | error | | > (1 row) > > This looks much nicer to me. > > One thing we lose is the caret marking the position of the error -- but > I'm wondering if that really works well. I didn't test it but from the > code it looks to me like it'd misbehave if you had a multiline statement. > > Opinions? Well, if you want nicely formated table you can always call the checker function directly, I think the statement returning something that is more human and less machine is more consistent approach with the rest of the utility commands. In other words I don't really see the point of it. Petr