On Wed, Jan 1, 2020 at 10:50 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > I know this is expected to happen considering the changes done in > above commit because from this commit onwards, NULL value assigned to > any row variable represents a true NULL composite value before this > commit it used to be a tuple with each column having null value in it. > But, the point is, even if the row variable is having a NULL value it > still has a structure associated with it. Shouldn't that structure be > transferred to RECORD variable when it is assigned with a ROW type > variable ? Can we consider this behaviour change as a side effect of > the improvement done in the RECORD type of variable?
I'm not an expert on this topic. However, I *think* that you're trying to distinguish between two things that are actually the same. If it's a "true NULL," it has no structure; it's just NULL. If it has a structure, then it's really a composite value with a NULL in each defined column, i.e. (NULL, NULL, NULL, ...) for some row type rather than just NULL.
I have to admit that I've always found PL/pgsql to be a bit pedantic about this whole thing. For instance:
rhaas=# do $$declare x record; begin raise notice '%', x.a; end;$$ language plpgsql; ERROR: record "x" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is indeterminate. CONTEXT: SQL statement "SELECT x.a" PL/pgSQL function inline_code_block line 1 at RAISE
But maybe it should just make x.a evaluate to NULL. It's one thing if I have a record with columns 'a' and 'b' and I ask for column 'c'; I guess you could call that NULL, but it feels reasonably likely to be a programming error. But if we have no idea what the record columns are at all, perhaps we could just assume that whatever column the user is requesting is intended to be one of them, and that since the whole thing is null, that column in particular is null.
I don't like this idea. We should not to invent record's fields created by reading or writing some field. At end it block any static code analyze and it can hide a errors. If we enhance a interface for json or jsonb, then this dynamic work can be done with these types.
We should to distinguish between typend and untyped NULL - it has sense for me (what was proposed by Ashutosh Sharma), but I don't see any sense to go far.
Regards
Pavel
On the other hand, maybe that would be too lenient and lead to subtle and hard-to-find bugs in plpgsql programs.
