Alvaro Herrera writes:
> Tom Lane wrote:
>> What is interesting is that the CASE in the OP's original submission
>> is apparently only there to dodge the visible-since-8.0 version of
>> the problem; at least I can't see that it does anything else useful.
>> The complaint apparently is not so much
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> With the fix I was just about to apply, all four cases give the first
> >> set of results. This clearly satisfies the principle of least
> >> astonishment, at least more nearly than what we have; but it equally
> >> clearly is
Heikki Linnakangas writes:
> Tom Lane wrote:
>> With the fix I was just about to apply, all four cases give the first
>> set of results. This clearly satisfies the principle of least
>> astonishment, at least more nearly than what we have; but it equally
>> clearly is *not* going to restore 8.4 t
Tom Lane wrote:
> With the fix I was just about to apply, all four cases give the first
> set of results. This clearly satisfies the principle of least
> astonishment, at least more nearly than what we have; but it equally
> clearly is *not* going to restore 8.4 to work just like 8.3.
Right, 8.3
I blithely opined:
> I believe BTW that there are related issues in other places where we
> expand composites into RowExprs. But the other places have been doing
> that for awhile. I think that for 8.4 our goals should be limited to
> not changing the behavior compared to prior releases.
So whil
I wrote:
> I think the problem is probably that we need a PlaceHolderVar wrapper
> around the ROW() constructor.
I looked into this a bit more. The issue is that flattening of
subqueries that are inside an outer join first puts PlaceHolderVars
around non-nullable output expressions of the subquer
On Tue, Sep 1, 2009 at 4:11 AM, Heikki
Linnakangas wrote:
> 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.
not just STRICT, but coalesce(), libpq 'is
Heikki Linnakangas writes:
> 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.
I think the problem is probably that we need a PlaceHolderVar wrapper
around the ROW() constructor.
> 2
2009/9/1 Heikki Linnakangas :
> 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 NU
Sheng Y. Cheng wrote:
> The Session 4.2.7. Aggregate Expressions in 8.3 document at
> http://www.postgresql.org/docs/8.3/static/sql-expressions.html states "The
> last form invokes the aggregate once for each input row regardless of null
> or non-null values." I am wondering if the result I saw fro
The following bug has been logged online:
Bug reference: 5025
Logged by: Sheng Y. Cheng
Email address: sch...@adconion.com
PostgreSQL version: 8.4.0 / 8.3.1
Operating system: Red Hat 4.1.1-52
Description:Aggregate function with subquery in 8.3 and 8.4.
Details:
Here
11 matches
Mail list logo
