On 10/31/2016 04:32 PM, Michael Moore wrote:
> I'm still a bit confused. If I replace the ROLLBACK; command with
> ELEPHANT; the result is a syntax error. Why doesn't ROLLBACK; produce
> the same error since it is not valid in the LANGUAGE plpgsql. I
> understand that "ROLLBACK TO SAVEPOINT" IS valid. But it's not the same
> thing.
I am guessing this:
https://www.postgresql.org/docs/9.5/static/plpgsql-implementation.html
" A disadvantage is that errors in a specific expression or command
cannot be detected until that part of the function is reached in
execution. (Trivial syntax errors will be detected during the initial
parsing pass, but anything deeper will not be detected until execution.)"
ROLLBACK might actually be valid at some point, ELEPHANT will not so it
caught in the trivial error stage.
>
> On Mon, Oct 31, 2016 at 3:55 PM, Michael Moore <michaeljmoore@gmail.com
> <mailto:michaeljmoore@gmail.com>> wrote:
>
> Cool, thanks David, I'll give it a read.
>
>
> On Mon, Oct 31, 2016 at 3:24 PM, David G. Johnston
> <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
>
> On Mon, Oct 31, 2016 at 3:13 PM, Michael Moore
> <michaeljmoore@gmail.com <mailto:michaeljmoore@gmail.com>>wrote:
>
> Here is the complete function, but all you need to look at
> is the exception block. (I didn't write this code) :-) I
> will ask the question after the code.
> [...]
>
> RETURN TRUE;
>
> EXCEPTION WHEN OTHERS THEN
>
> RAISE EXCEPTION '% %', SQLERRM, SQLSTATE;
>
> ROLLBACK;
>
> RETURN FALSE;
>
> END;
>
> $BODY$
>
> LANGUAGE plpgsql VOLATILE
>
> COST 100;
>
>
> So, here is the question. Why does the compiler not catch:
>
> 1) ROLLBACK; is not a valid PL/pgSQL command
>
>
> R
> eading section 41.10.2 at the linked page should answer this part.
>
> https://www.postgresql.org/docs/current/static/plpgsql-implementation.html
> <https://www.postgresql.org/docs/current/static/plpgsql-implementation.html>
>
>
> 2) ROLLBACK; and RETURN FALSE; can never be reached
>
>
>
> Similar to the above - though "static analysis" is yet a step
> beyond even what the syntax checking skipping covered above
> would reveal.
>
> David J.
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com