Thread: Bug in GET STACKED DIAGNOSTICS ?

Bug in GET STACKED DIAGNOSTICS ?

From
Dan S
Date:
Hi !

I'm running "PostgreSQL 9.2.2 on i686-pc-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 32-bit" on  ubuntu 12.04 .

I'm a bit perplexed by the difference in PG_EXCEPTION_CONTEXT of the following two invocations of a function where I try to get the call stack.
Is this expected behaviour ?

First invocation (This is the one where I get the expected notification):

select * from testfunc2(true);

NOTICE:  PL/pgSQL function testfunc(boolean) line 8 at assignment
PL/pgSQL function testfunc2(boolean) line 6 at RETURNs


Second invocation (I did expect two rows of callstack here also but I only got one):

select * from testfunc2(false);

NOTICE:  PL/pgSQL function testfunc2(boolean) line 6 at RETURNs

The functions:

CREATE OR REPLACE FUNCTION testfunc( div_by_zero boolean )
  RETURNS text AS
$BODY$
DECLARE
    td  text;
    i int = 0;
BEGIN
    BEGIN
        IF div_by_zero THEN
            i = 1/i;
        ELSE
            RAISE EXCEPTION 'an exception';
        END IF;
    EXCEPTION WHEN raise_exception OR division_by_zero THEN
        GET STACKED DIAGNOSTICS td = PG_EXCEPTION_CONTEXT;
        RAISE NOTICE '%s',td;
    END;
    RETURN td::text;
END;
$BODY$
  LANGUAGE plpgsql;


CREATE OR REPLACE FUNCTION testfunc2(div_by_zero boolean)
  RETURNS text AS
$BODY$
DECLARE
    td  text;
    i int = 0;
BEGIN
    return testfunc(div_by_zero);
END;
$BODY$
  LANGUAGE plpgsql;


Best Regards
Dan S

Re: Bug in GET STACKED DIAGNOSTICS ?

From
Pavel Stehule
Date:
Hello

2012/12/10 Dan S <strd911@gmail.com>:
> Hi !
>
> I'm running "PostgreSQL 9.2.2 on i686-pc-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 32-bit" on  ubuntu 12.04 .
>
> I'm a bit perplexed by the difference in PG_EXCEPTION_CONTEXT of the
> following two invocations of a function where I try to get the call stack.
> Is this expected behaviour ?
>
> First invocation (This is the one where I get the expected notification):
>
> select * from testfunc2(true);
>
> NOTICE:  PL/pgSQL function testfunc(boolean) line 8 at assignment
> PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>
>
> Second invocation (I did expect two rows of callstack here also but I only
> got one):
>
> select * from testfunc2(false);
>
> NOTICE:  PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>

It is feature, not e bug - although I don't sure what is sense of this feature.

plpgsql_exec_error_callback(void *arg)
{
        PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;

        /* if we are doing RAISE, don't report its location */
        if (estate->err_text == raise_skip_msg)
                return;

we don't attach context for RAISE statement.

Regards

Pavel Stehule

> The functions:
>
> CREATE OR REPLACE FUNCTION testfunc( div_by_zero boolean )
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     BEGIN
>         IF div_by_zero THEN
>             i = 1/i;
>         ELSE
>             RAISE EXCEPTION 'an exception';
>         END IF;
>     EXCEPTION WHEN raise_exception OR division_by_zero THEN
>         GET STACKED DIAGNOSTICS td = PG_EXCEPTION_CONTEXT;
>         RAISE NOTICE '%s',td;
>     END;
>     RETURN td::text;
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> CREATE OR REPLACE FUNCTION testfunc2(div_by_zero boolean)
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     return testfunc(div_by_zero);
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> Best Regards
> Dan S
>


Re: Bug in GET STACKED DIAGNOSTICS ?

From
Dan S
Date:
It would be nice with a consistent behaviour, with the callstack always looking the same despite different causes of the exception.
I think it is violating the 'Principle of least astonishment' .

Best Regards
Dan S

2012/12/11 Pavel Stehule <pavel.stehule@gmail.com>
Hello

2012/12/10 Dan S <strd911@gmail.com>:
> Hi !
>
> I'm running "PostgreSQL 9.2.2 on i686-pc-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 32-bit" on  ubuntu 12.04 .
>
> I'm a bit perplexed by the difference in PG_EXCEPTION_CONTEXT of the
> following two invocations of a function where I try to get the call stack.
> Is this expected behaviour ?
>
> First invocation (This is the one where I get the expected notification):
>
> select * from testfunc2(true);
>
> NOTICE:  PL/pgSQL function testfunc(boolean) line 8 at assignment
> PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>
>
> Second invocation (I did expect two rows of callstack here also but I only
> got one):
>
> select * from testfunc2(false);
>
> NOTICE:  PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>

It is feature, not e bug - although I don't sure what is sense of this feature.

plpgsql_exec_error_callback(void *arg)
{
        PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;

        /* if we are doing RAISE, don't report its location */
        if (estate->err_text == raise_skip_msg)
                return;

we don't attach context for RAISE statement.

Regards

Pavel Stehule

> The functions:
>
> CREATE OR REPLACE FUNCTION testfunc( div_by_zero boolean )
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     BEGIN
>         IF div_by_zero THEN
>             i = 1/i;
>         ELSE
>             RAISE EXCEPTION 'an exception';
>         END IF;
>     EXCEPTION WHEN raise_exception OR division_by_zero THEN
>         GET STACKED DIAGNOSTICS td = PG_EXCEPTION_CONTEXT;
>         RAISE NOTICE '%s',td;
>     END;
>     RETURN td::text;
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> CREATE OR REPLACE FUNCTION testfunc2(div_by_zero boolean)
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     return testfunc(div_by_zero);
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> Best Regards
> Dan S
>

Re: Bug in GET STACKED DIAGNOSTICS ?

From
Dan S
Date:
I got another unexpected behaviour of the call stack by this invocation  :

select testfunc2(true) from generate_series(1,10);

The first call stack is different from the nine folllowing.
Shouldn't it be identical to the others ?

Best Regards
Dan S

2012/12/11 Pavel Stehule <pavel.stehule@gmail.com>
Hello

2012/12/10 Dan S <strd911@gmail.com>:
> Hi !
>
> I'm running "PostgreSQL 9.2.2 on i686-pc-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 32-bit" on  ubuntu 12.04 .
>
> I'm a bit perplexed by the difference in PG_EXCEPTION_CONTEXT of the
> following two invocations of a function where I try to get the call stack.
> Is this expected behaviour ?
>
> First invocation (This is the one where I get the expected notification):
>
> select * from testfunc2(true);
>
> NOTICE:  PL/pgSQL function testfunc(boolean) line 8 at assignment
> PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>
>
> Second invocation (I did expect two rows of callstack here also but I only
> got one):
>
> select * from testfunc2(false);
>
> NOTICE:  PL/pgSQL function testfunc2(boolean) line 6 at RETURNs
>

It is feature, not e bug - although I don't sure what is sense of this feature.

plpgsql_exec_error_callback(void *arg)
{
        PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;

        /* if we are doing RAISE, don't report its location */
        if (estate->err_text == raise_skip_msg)
                return;

we don't attach context for RAISE statement.

Regards

Pavel Stehule

> The functions:
>
> CREATE OR REPLACE FUNCTION testfunc( div_by_zero boolean )
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     BEGIN
>         IF div_by_zero THEN
>             i = 1/i;
>         ELSE
>             RAISE EXCEPTION 'an exception';
>         END IF;
>     EXCEPTION WHEN raise_exception OR division_by_zero THEN
>         GET STACKED DIAGNOSTICS td = PG_EXCEPTION_CONTEXT;
>         RAISE NOTICE '%s',td;
>     END;
>     RETURN td::text;
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> CREATE OR REPLACE FUNCTION testfunc2(div_by_zero boolean)
>   RETURNS text AS
> $BODY$
> DECLARE
>     td  text;
>     i int = 0;
> BEGIN
>     return testfunc(div_by_zero);
> END;
> $BODY$
>   LANGUAGE plpgsql;
>
>
> Best Regards
> Dan S
>