2010/8/1 Robert Haas <robertmh...@gmail.com>: > On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Pavel Stehule <pavel.steh...@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.
ok - tomorrow I'll send a patch Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
