2010/8/11 Robert Haas <robertmhaas@gmail.com>:
> 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.
>
the proposed changes are not complex, and there are not reason to move
\sf to next commitfest. I am thinking about little bit simplification
- there can by only one cycle without two. After \e commiting there
are other complex code. If some code isn't clean, then it is because
there are \o and pager support.
> 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.
>
+1
Regards
Pavel Stehule
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>