On Sun, Aug 1, 2010 at 11:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane <t...@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.
I basically agree with that; but on the other hand, in a large PL/pgsql function, you may have very similar-looking text in multiple places. So line numbers are good, too: but then you weren't proposing to remove those, I assume, just to augment them with additional information. -- 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
