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

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 (view raw or flat)
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

pgsql-hackers by date

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

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