From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | pinker <pinker(at)onet(dot)eu> |
Cc: | "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Error prone compilation of stored procedure |
Date: | 2015-07-06 10:50:02 |
Message-ID: | CAFj8pRAFm4+KE8ACb+fQ73b1t4TGeH8N7LLDQXb+kqObe6F1Ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2015-07-06 12:08 GMT+02:00 pinker <pinker(at)onet(dot)eu>:
> What's the reason behind very "tolerant" error checking during stored
> procedure compilation?
> Why PostgreSQL allows using variable (j_var) that doesn't exists? It isn't
> column name or isn't declared anywhere. Like in example below:
>
> CREATE OR REPLACE FUNCTION test()
> RETURNS int AS
> $BODY$
> BEGIN
>
> select 1 WHERE 1 > j_var;
> RETURN 2;
> END;
> $BODY$
> LANGUAGE plpgsql VOLATILE
> COST 100;
>
PLpgSQL doesn't check a identifiers inside embedded SQL before execution.
In this case j_var can be theoretically some SQL identifiers - the
possibility or impossibility is not know in function validation stage.
It has some plus and minus points. The plus - there are not strong
dependency between database objects and PL code. The minus - lot of bugs
are not detected in validation stage. But this issue can be solved by
plpgsql_check extension https://github.com/okbob/plpgsql_check/
Regards
Pavel
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | pinker | 2015-07-06 11:43:02 | Re: Error prone compilation of stored procedure |
Previous Message | Andreas Kretschmer | 2015-07-06 10:39:07 | Re: Error prone compilation of stored procedure |