Skip site navigation (1) Skip section navigation (2)

Re: proposal - structured funcid and lineno as new fields in error message

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - structured funcid and lineno as new fields in error message
Date: 2010-03-29 16:47:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/3/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.

Pavel Stehule

>                        regards, tom lane

In response to


pgsql-hackers by date

Next:From: Łukasz DejnekaDate: 2010-03-29 17:05:44
Subject: Re: Using HStore type in TSearch
Previous:From: Greg SmithDate: 2010-03-29 16:33:00
Subject: Re: enable_joinremoval

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group