From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
Cc: | 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 18:56:48 |
Message-ID: | CA+Tgmob2VfpDgmPHxKNYtMXpTcUhmShsrLt4M+vy7Cins1f_Uw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2020-01-03 18:57:42 | Re: Greatest Common Divisor |
Previous Message | Tom Lane | 2020-01-03 18:48:56 | Re: [PATCH] Increase the maximum value track_activity_query_size |