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

From Tom Lane
Subject Re: review: psql: edit function, show function commands patch
Date
Msg-id 6717.1280676934@sss.pgh.pa.us
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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The need to count lines manually in function definitions is
>> far less than it was back when that kluge was put in.

> Why?

That hack goes back to plpgsql's prehistory (it's there, though sans
comment, in plpgsql's scan.l 1.1).  We had none of the current support
for identifying error locations by cursor position and/or quoting part
of the source text back at you.  Let me illustrate what happened with
a simple syntax error in PG 7.0:

play=> create function fool() returns int as '
play'> begin
play'>   fool
play'> end' language 'plpgsql';
CREATE
play=> select fool();
NOTICE:  plpgsql: ERROR during compile of fool near line 2
ERROR:  missing ; at end of SQL statement
play=> 

So you *had* to count lines, and do it accurately too, to figure out
even pretty simple syntax errors.

Personally, rather than sweat about what the exact definition of line
numbers is, I think we should be moving further in the direction of
being able to regurgitate source text to identify error locations.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: ANALYZE versus expression indexes with nondefault opckeytype
Next
From: Tom Lane
Date:
Subject: Re: ANALYZE versus expression indexes with nondefault opckeytype