Re: Assigning ROW variable having NULL value to RECORD type variable doesn't give any structure to the RECORD variable.

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Assigning ROW variable having NULL value to RECORD type variable doesn't give any structure to the RECORD variable.
Date: 2020-01-03 19:39:25
Message-ID: CAFj8pRCGhVs0eh8U1V_Sm8LhpNTnYV2RFy+iUAmppMY7-f9a7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pá 3. 1. 2020 v 19:57 odesílatel Robert Haas <robertmhaas(at)gmail(dot)com> napsal:

> On Wed, Jan 1, 2020 at 10:50 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)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
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robbie Harwood 2020-01-03 20:01:25 Re: weird libpq GSSAPI comment
Previous Message Stephen Frost 2020-01-03 19:35:59 Re: backup manifests