pá 3. 1. 2020 v 19:57 odesílatel Robert Haas <robertmh...@gmail.com> napsal:
> On Wed, Jan 1, 2020 at 10:50 AM Ashutosh Sharma <ashu.coe...@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. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > >