Re: review: psql: edit function, show function commands patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: psql: edit function, show function commands patch
Date: 2010-08-11 16:28:44
Message-ID: 7470.1281544124@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
>> seems grossly overdesigned. It would be clearer, shorter, and faster if
>> you just had a strncmp test for "AS $function" there.

> As far as I can see, the only purpose of that code is to support the
> desire to have \sf+ display **** rather than a line number for the
> lines that FOLLOW the function body. But I'm wondering if we should
> just forget about that and let the numbering run continuously from the
> first "AS $function" line to end of file. That would get rid of a
> bunch of rather grotty code in the \sf patch, also.

Oh? Considering that in the standard pg_get_functiondef output, the
ending $function$ delimiter is always on the very last line, that sounds
pretty useless. +1 for just numbering forward from the start line.

BTW, the last I looked, \sf+ was using what I thought to be a quite ugly
and poorly-considered formatting for the line number. I would suggest
eight blanks for a header line and "%-7d " as the prefix format for a
numbered line. The reason for making sure the prefix is 8 columns rather
than some other width is to not mess up tab-based formatting of the
function body. I would also prefer a lot more visual separation between
the line number and the code than "%4d " will offer; and as for the
stars, they're just useless and distracting.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-11 16:36:52 Re: string_to_array with an empty input string
Previous Message David E. Wheeler 2010-08-11 16:23:49 Re: string_to_array with an empty input string