> On Jul 28, 2022, at 18:49, Bryn Llewellyn <bryn@xxxxxxxxxxxx> wrote:
> It's this that surprises me. And it's this, and only this, that I'm asking about: might _just_ this be a fixable bug?
It might be surprising, but it's not a bug. You can demonstrate it with a very small test case:
CREATE FUNCTION f() RETURNS VOID AS $$
DECLARE
x int not null := 0;
BEGIN
x := y;
END;
$$ language plpgsql;
But gets an error on execution:
xof=# SELECT f();
ERROR: column "y" does not exist
LINE 1: x := y
^
QUERY: x := y
CONTEXT: PL/pgSQL function f() line 5 at assignment
The clue is that it is complaining about a missing "column." Assignment in PL/pgSQL is essentially syntactic sugar around a SELECT ... INTO. The assignment there is processed pretty much as if it were written:
SELECT y INTO x;
Note, however, that this does *not* compile:
CREATE OR REPLACE FUNCTION f() RETURNS VOID AS $$
DECLARE
x int not null := 0;
BEGIN
y := x;
END;
$$ language plpgsql;
ERROR: "y" is not a known variable
LINE 5: y := x;
Unquestionably, this is surprising! The reasons, such as they are, are based in how PL/pgSQL processes SQL statements. (For example, if you look at the grammar, it literally takes "SELECT x INTO y;" turns it into "SELECT x ;", and passes that to the SPI. This has the virtue that it doesn't have to have a complete PostgreSQL SQL grammar replicated in it (what a nightmare), but it does result in some of the implementation poking through.
