proposal - structured funcid and lineno as new fields in error message
in [PgSql]
|
Prev: [HACKERS] psql: edit function, show function commands patch
Next: [HACKERS] I am interested in the MERGE command implementation as my gSoC project
From: Tom Lane on 29 Mar 2010 12:32 Pavel Stehule <pavel.stehule(a)gmail.com> writes: > can we add well structured information about function id and lineno to > ErrorData? The idea that I was toying with was to report the function OID and line number, which might as well be two separate fields rather than messing around with anything "structured". The OID might be a bit inconvenient from the client side, but the trouble with trying to do more is that constructing a complete function descriptor will require catalog lookups, which is exactly what you don't want to be doing in an already-failed transaction. (We just fixed some bugs along that line :-() In any case, the real problem we have is not so much that we lack error message fields: the messages we emit for plpgsql syntax errors are quite complete already. The work that is needed is to provide that same infrastructure for run-time errors. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 29 Mar 2010 12:47
2010/3/29 Tom Lane <tgl(a)sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule(a)gmail.com> writes: >> can we add well structured information about function id and lineno to >> ErrorData? > > The idea that I was toying with was to report the function OID and line > number, which might as well be two separate fields rather than messing > around with anything "structured". > > The OID might be a bit inconvenient from the client side, but the > trouble with trying to do more is that constructing a complete function > descriptor will require catalog lookups, which is exactly what you don't > want to be doing in an already-failed transaction. Â (We just fixed some > bugs along that line :-() > > In any case, the real problem we have is not so much that we lack error > message fields: the messages we emit for plpgsql syntax errors are quite > complete already. Â The work that is needed is to provide that same > infrastructure for run-time errors. I thinking about it as some tool for some admin sw. But it is little bit more complex than I though :(. More times we doesn't need oid of really last function - mostly will be some C function - so we have to have some like stack. I understand so we have to do rollback before any using of oid. But I have to do it in all cases - only oid is useless, we need source code - so rollback is necessary. These information can exists together with current informations - like show some for fast info before rollback and show more detailed info after rollback. Some parts of error data are saved before rollback - but it is task for client. Regards Pavel Stehule > > Â Â Â Â Â Â Â Â Â Â Â Â regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |