Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »

pá 29. 7. 2022 v 4:57 odesílatel Bryn Llewellyn <bryn(at)yugabyte(dot)com> napsal:

>
> *tgl(at)sss(dot)pgh(dot)pa(dot)us <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:*
>
> xof(at)thebuild(dot)com wrote:
>
> This isn't a bug.
>
>
> It's actually a feature…
>
> Having said that, there are certainly aspects of what happens when in
> plpgsql that don't have a lot of justification other than
> being implementation artifacts…
>
>
> Thanks, Tom. I'll take your « aspects of… plpgsql [are simply]
> implementation artifacts » to mean that my hope to understand what is
> checked at "create or replace <my subprogram>" time and what is checked
> first at runtime is futile.
>
> There does seem to be a general rule. But, as my example shows, there are
> exceptions to the rule. And it's impossible to make a simple user-facing
> statement of what determines "exceptional" status.
>
> I suppose that the conclusion is clear: you can't be sure that a
> subprogram is good until every single code path (in the basic block
> coverage sense of this) has been tested. But, anyway, it was ever thus.
> (Error-free compilation never did guarantee error-free runtime outcomes.)
>

plpgsql_check https://github.com/okbob/plpgsql_check can help with it. It
does full static (without execution) analyze

Regards

Pavel

> I'll call this "case closed" then.
>