Re: [GENERAL] Error prone compilation of stored procedure

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 s

Re: [GENERAL] Error prone compilation of stored procedure

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 mail

Re: [GENERAL] Error prone compilation of stored procedure

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

Re: [GENERAL] Error prone compilation of stored procedure

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

Re: [GENERAL] Error prone compilation of stored procedure

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

Re: [GENERAL] Error prone compilation of stored procedure

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

Re: [GENERAL] Error prone compilation of stored procedure

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 F

Re: [GENERAL] Error prone compilation of stored procedure

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.

[GENERAL] Error prone compilation of stored procedure

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 s