pá 29. 7. 2022 v 4:57 odesílatel Bryn Llewellyn <b...@yugabyte.com> napsal:
> > *t...@sss.pgh.pa.us <t...@sss.pgh.pa.us> wrote:* > > x...@thebuild.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. >
