Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Sheng Y(dot) Cheng" <scheng(at)adconion(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.
Date: 2009-09-01 10:48:47
Message-ID: e08cc0400909010348g78913907k1e3a4ce6855c2d13@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

2009/9/1 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> I can see two possible interpretations for this:
>
> 1. The subquery pull-up code is broken, the transformation of a
> whole-row reference to ROW(...) is not valid.
>
> 2. The semantics of STRICT with row arguments is broken. It should be
> made consistent with IS NULL. Strict function should not be called if
> the argument is a row value with all NULL columns.
>
> I'm not sure which interpretation is correct. Thoughts? The SQL spec
> probably has something to say about this.

I suppose ts.* that wasn't joined is NULL. Not "a row value with all
NULL columns" but "a NULL row value".

contrib_regression=# SELECT t1.f1, ts.* IS NULL, ts.* FROM
t1
LEFT JOIN
(SELECT
f1
FROM t2
-- offset 0
) AS ts
ON
t1.f1 = ts.f1
;
f1 | ?column? | f1
-----+----------+-----
aaa | t |
bbb | f | bbb
ccc | t |
(3 rows)

So the 1. ROW(...) construction seems not valid.

>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

Regards,

--
Hitoshi Harada

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2009-09-01 11:35:48 Re: inconsistent composite type null handling in plpgsql out variable
Previous Message Sam Mason 2009-09-01 09:35:09 Re: inconsistent composite type null handling in plpgsql out variable