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

Re: enhanced error fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Geoghegan <peter(dot)geoghegan86(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:56:42
Message-ID: CAFj8pRArqMwG7YD2cMTcUW9vwBi8YAegENJddCO82szZa9HCsA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2013/1/29 Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>:
> 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.

in this meaning is not too useful as I expected.

>
> 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).

I checked performance and Robert too, and there is not significant slowdown.

if I do

DROP FUNCTION inner(int);
DROP FUNCTION middle(int);
DROP FUNCTION outer();


CREATE OR REPLACE FUNCTION inner(int)
RETURNS int AS $$
BEGIN
  RETURN 10/$1;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION middle(int)
RETURNS int AS $$
BEGIN
  RETURN inner($1);
END;
$$ LANGUAGE plpgsql;


CREATE OR REPLACE FUNCTION outer()
RETURNS int AS $$
DECLARE
  text_var1 text;
BEGIN
  RETURN middle(0);
EXCEPTION WHEN OTHERS THEN
  GET STACKED DIAGNOSTICS text_var1 = PG_EXCEPTION_CONTEXT;
  RAISE NOTICE '>>%<<', text_var1;
  RETURN -1;
END;
$$ LANGUAGE plpgsql;

SELECT outer();

then output is

psql:test.psql:34: NOTICE:  >>PL/pgSQL function "inner"(integer) line
3 at RETURN
PL/pgSQL function middle(integer) line 3 at RETURN
PL/pgSQL function "outer"() line 5 at RETURN<<

I have not any possibility to take information about source of
exception without parsing context - and a string with context
information can be changed, so it is not immutable and not easy
accessible. Why I need this info - sometimes when I can log some info
about handled exception I don't would log a complete context due size
and due readability.

Another idea - some adjusted parser of context message can live in GET
STACKED DIAGNOSTICS implementation - so there can be some custom field
(just for GET STACKED DIAG.) that returns expected value. But this
value should be taken from context string with parsing - that is not
nice - but possible - I did similar game in orafce.

Regards

Pavel

>
> --
> Regards,
> Peter Geoghegan


In response to

pgsql-hackers by date

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

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