Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4. - Mailing list pgsql-bugs

From Hitoshi Harada
Subject Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.
Date
Msg-id e08cc0400909010348g78913907k1e3a4ce6855c2d13@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
2009/9/1 Heikki Linnakangas <heikki.linnakangas@enterprisedb.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

Regards,

--
Hitoshi Harada

pgsql-bugs by date:

Previous
From: Sam Mason
Date:
Subject: Re: inconsistent composite type null handling in plpgsql out variable
Next
From: Pavel Stehule
Date:
Subject: Re: inconsistent composite type null handling in plpgsql out variable