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

From Bryn Llewellyn
Subject Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Date
Msg-id 4DC7ED5B-BADD-4330-B481-76490D3B319E@yugabyte.com
Whole thread Raw
In response to Re: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
List pgsql-general

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.)

I'll call this "case closed" then.

pgsql-general by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Next
From: Pavel Stehule
Date:
Subject: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »