Re: enhanced error fields

From: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "anarazel(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: enhanced error fields
Date: 2013-01-29 17:13:52
Message-ID: CAEYLb_W-ELsPq18g4d+k-A_uW0WpQN_nP+7r-8RabX8740aA3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29 January 2013 17:05, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-01-29 17:18:54 Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Previous Message Pavel Stehule 2013-01-29 17:05:42 Re: enhanced error fields