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

From Alvaro Herrera
Subject Re: review: CHECK FUNCTION statement
Date
Msg-id 1330803772-sup-3190@alvh.no-ip.org
Whole thread Raw
In response to Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: review: CHECK FUNCTION statement
List 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@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Patch: improve selectivity estimation for IN/NOT IN
Next
From: Simon Riggs
Date:
Subject: Re: COPY with hints, rebirth