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

From Pavel Stehule
Subject Re: review: psql: edit function, show function commands patch
Date
Msg-id AANLkTi=4KrhgngEnASJC2vOBDudQpNGWq3LmYTXQKMxo@mail.gmail.com
Whole thread Raw
In response to Re: review: psql: edit function, show function commands patch  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: review: psql: edit function, show function commands patch
List pgsql-hackers
Hello

I am sending a modified patch - changes:

a) remove special row number handling of plpgsql (first patch)
b) more robust algorithm for header rows identification

Regards

Pavel Stehule

2010/8/1 Robert Haas <robertmhaas@gmail.com>:
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>> so my plan
>>
>>> a) fix problem with ambiguous $function* like you proposed
>>> b) fix problem with "first row excepting" - I can activate a detection
>>> only for plpgsql language - I can identify LANGUAGE before.
>>
>> Ick.  We should absolutely NOT have a client-side special case for plpgsql.
>>
>> Personally I'd be fine with dropping the special case from the plpgsql
>> parser --- I don't believe that that behavior was ever discussed, much
>> less documented, and I doubt that many people rely on it or even know
>> it exists.
>
> +1.
>
>> The need to count lines manually in function definitions is
>> far less than it was back when that kluge was put in.
>
> Why?
>
>> If anyone can make a convincing case that it's a good idea to ignore
>> leading newlines, we should reimplement the behavior in such a way that
>> it applies across the board to all PLs (ie, make CREATE FUNCTION strip
>> a leading newline before storing the text).  However, then you'd have
>> issues about whether or when to put back the newline, so I'm not really
>> in favor of that route.
>
> Ditto.
>
> As a procedural note, if we decide to go this route, this should be
> split into two patches - one that removes the line-numbering kludge,
> and a second for the psql changes.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ANALYZE versus expression indexes with nondefault opckeytype
Next
From: Mike Fowler
Date:
Subject: Initial review of xslt with no limits patch