Re: enhanced error fields - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: enhanced error fields
Date
Msg-id CAEYLb_W-ELsPq18g4d+k-A_uW0WpQN_nP+7r-8RabX8740aA3A@mail.gmail.com
Whole thread Raw
In response to Re: enhanced error fields  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: enhanced error fields
List pgsql-hackers
On 29 January 2013 17:05, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Perhaps I'm mistaken, but I can't imagine that it would be terribly
>> useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
>> ROUTINE_NAME.
>
> I hoped so I can use it inside exception handler

Right, but is that really any use to you if it becomes available for a
small subset of errors, specifically, errors that directly relate to
the function? You're not going to be able to use it to trace the
function where an arbitrary error occurred, if we do something
consistent with GET DIAGNOSTICS as described by the SQL standard, it
seems.

I think that what the SQL standard intends here is actually consistent
with what we're going to do with CONSTRAINT_NAME and so on. I just
happen to think it's much less interesting, but am not opposed to it
in principle (though I may oppose it in practice, if writing the
feature means bloating up errdata).

-- 
Regards,
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: enhanced error fields
Next
From: Pavel Stehule
Date:
Subject: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used