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
>
>
>
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 |