Re: review: CHECK FUNCTION statement

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Petr Jelínek <pjmodos(at)pjmodos(dot)net>, Greg Smith <greg(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: review: CHECK FUNCTION statement
Date: 2012-03-03 19:54:19
Message-ID: 1330803772-sup-3190@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012:
> Hello
>
> >
> > It wasn't all that difficult -- see below.  While at this, I have a
> > question: how attached you are to the current return format for CHECK
> > FUNCTION?
>
> TupleDescr is created by language creator. This ensure exactly
> expected format, because there are no possible registry check function
> with other output tuple descriptor.

I'm not sure what you're saying. What TupDesc are you talking about?
The tupdesc returned by the checker is certainly hardcoded by the core
support; the language creator cannot deviate from it.

> > 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.
>
> I am strongly disagree.
>
> 1. This format is not consistent with other commands,
> 2. This format is difficult for copy/paste
> 3. THE ARE NOT CARET - this is really important
> 5. This form is bad for terminals - there are long rows, and with \x
> outout, there are lot of "garbage" for multicommand
> 4. When you would to this form, you can to directly call SRF PL check
> functions.

I am not sure that consistency is the most important thing here; I think
what we care about is that it's usable. So yeah, it might be hard to
cut and paste, and also too wide. Maybe we can run some of the fields
together, and omit others.

I am not sure about the caret thingy -- mainly because I don't think it
works all that well. I don't know how psql does it, but I notice that
it shows a single line in a multiline query -- so it's not just a matter
of adding some number of spaces.

Given the negative feedback, I'm going to leave this output format
unchanged; we can tweak it later.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-03-03 20:22:59 tuplesort memory usage: grow_memtuples
Previous Message Simon Riggs 2012-03-03 19:53:31 Re: COPY with hints, rebirth