| From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Oleg Serov <serovov(at)gmail(dot)com> |
| Subject: | Re: Null row vs. row of nulls in plpgsql |
| Date: | 2008-09-28 11:45:03 |
| Message-ID: | 1222602303.7044.6.camel@huvostro |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2008-09-28 at 04:03 +0300, Greg Stark wrote:
> Iirc the reason for this fuzziness came from the SQL spec definition
> of IS NULL for rows. As long as you maintain that level of spec-
> compliance I don't think there are any other important constraints on
> pg behaviour.
What does SQL spec say about recursive IS NULL for rows ?
Should we check that IS NULL is true for each row element, or must they
actually be NULL's ?
hannu=# select row(null, null) is NULL;
?column?
----------
t
(1 row)
hannu=# select row(null, row(null, null)) is NULL;
?column?
----------
f
(1 row)
--------------
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-09-28 17:15:49 | Re: FSM rewrite: doc changes |
| Previous Message | Stefan Kaltenbrunner | 2008-09-28 10:00:34 | Re: [HACKERS] planned maintenance downtime - tribble.postgresql.org |