Re: [GENERAL] Error prone compilation of stored procedure

[Andreas Kretschmer]

pinker  wrote:

> What's the reason behind very "tolerant" error checking during stored
> procedure compilation?

they are not compiled but interpreted at runtime.


Andreas
-- 
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.  (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.  N 51.05082°, E 13.56889°


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error prone compilation of stored procedure

[Pavel Stehule]

2015-07-06 12:08 GMT+02:00 pinker :

> 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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Error prone compilation of stored procedure

[pinker]

Andreas Kretschmer-2 wrote
> pinker <

> pinker@

> > wrote:> What's the reason behind very "tolerant" error checking
> during stored> procedure compilation?they are not compiled but interpreted
> at runtime.Andreas

Documentation says:  during the compilation of a function
  I
know it's not classic one, but still this word is used in this context.



--
View this message in context: 
http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699p5856707.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Re: [GENERAL] Error prone compilation of stored procedure

[pinker]

Pavel Stehule wrote
> 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/

Thank you for the link to extension. 
Another minus is that my colleagues which use to work on oracle think that
postgresql is at least one league below oracle.



--
View this message in context: 
http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699p5856708.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error prone compilation of stored procedure

[Andrew Sullivan]

On Mon, Jul 06, 2015 at 04:52:52AM -0700, pinker wrote:
> Another minus is that my colleagues which use to work on oracle think that
> postgresql is at least one league below oracle.

I find that people who are used to any one tool always point out how
some other tool is deficient, even if they're raving about other
advantages.  This is especially the case when there are trade-offs
involved in the way a tool does a thing.  My suggestion is to point
out that if one hates $feature, one can extend Postgres to make it go
away, a capability not available in Oracle at any price.  At least, I
found that to be useful when talking to Oracle partisans.

A

-- 
Andrew Sullivan
a...@crankycanuck.ca


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error prone compilation of stored procedure

[Rob Sargent]

And are your colleagues offering to pay for an Oracle license?

> On Jul 6, 2015, at 5:52 AM, pinker  wrote:
> 
> Pavel Stehule wrote
>> 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/
> 
> Thank you for the link to extension. 
> Another minus is that my colleagues which use to work on oracle think that
> postgresql is at least one league below oracle.
> 
> 
> 
> --
> View this message in context: 
> http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699p5856708.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error prone compilation of stored procedure

[pinker]

lup wrote
> And are your colleagues offering to pay for an Oracle license?

I would prefer to prove them it's not necessary :)



--
View this message in context: 
http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699p5856734.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error prone compilation of stored procedure

[Pavel Stehule]

2015-07-06 13:52 GMT+02:00 pinker :

> Pavel Stehule wrote
> > 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/
>
> Thank you for the link to extension.
> Another minus is that my colleagues which use to work on oracle think that
> postgresql is at least one league below oracle.
>

why minus? - The dependency in PL/SQL is hell - it strongly increase a
complexity of lot of tasks.  The plpgsql is designed to be simple as
possible - but it has the power of PL/SQL. If you need to check your
PLpgSQL code, just install plpgsql_check extension.

Regards

Pavel

>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/Error-prone-compilation-of-stored-procedure-tp5856699p5856708.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>