Re: review: psql: edit function, show function commands patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: review: psql: edit function, show function commands patch
Date
Msg-id AANLkTinLr-b8qNyw2JXPd1a8U-DtYX4gjkJ0VRkTuzdX@mail.gmail.com
Whole thread Raw
In response to Re: review: psql: edit function, show function commands patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: review: psql: edit function, show function commands patch
Re: review: psql: edit function, show function commands patch
List pgsql-hackers
On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane <tgl@sss.pgh.pa.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.

OK.

> 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.

I don't have a strong preference, but that seems reasonable.  I
suggest that we punt the \sf portion of this patch back for rework for
the next CommitFest, and focus on getting the \e and \ef changes
committed.  I think the \sf code can be a lot simpler if we get rid of
the code that's intended to recognize the ending delimeter.

Another thought is that we might want to add a comment to
pg_get_functiondef() noting that anyone changing the output format
should be careful not to break the line-number-finding form of \ef in
the process.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: string_to_array with an empty input string
Next
From: Robert Haas
Date:
Subject: Re: string_to_array with an empty input string