| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: more practical view on function's source code |
| Date: | 2010-03-21 18:08:57 |
| Message-ID: | 24892.1269194937@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> I'm not sure what better tool than what Pavel is proposing we already
> have, though.
We have quite decent features for localizing syntax errors in functions, eg
regression=# create function foo(x int) returns int language plpgsql as $$
begin
return 1/;
end$$;
ERROR: syntax error at end of input
LINE 3: return 1/;
^
regression=#
What I think is called for is extending that approach to run-time
errors. plpgsql doesn't make any particular effort to provide that
right now, but it easily could IMO. Pavel's proposal is only of use to
people using psql, which is not everyone --- and it seems pretty awkward
to me even for psql users.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-03-21 19:01:37 | Re: proposal: more practical view on function's source code |
| Previous Message | Andrew Dunstan | 2010-03-21 18:00:31 | Re: proposal: more practical view on function's source code |