2013/1/29 Peter Geoghegan <peter.geoghegan86@gmail.com>:
> 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.
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