Re: BUG #13863: Select from views gives wrong results

From: Andres Freund <andres(at)anarazel(dot)de>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: wrb <wrb(at)autistici(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13863: Select from views gives wrong results
Date: 2016-01-16 13:12:02
Message-ID: 20160116131202.GP10941@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

Thanks for digging!

On 2016-01-16 11:23:31 +0000, Dean Rasheed wrote:
> When the clause is pushed down into the view it is turned from a WHERE
> clause into a HAVING clause, because the view query has grouping. That
> part is OK. However, the query planner then decides that since the new
> HAVING clause doesn't contain any aggregates or volatile expressions,
> it is safe to turn it back into a WHERE clause in the inner query.
> That would be OK for normal grouping, because in that case the clause
> would evaluate the same for all the rows in a group. However, that
> doesn't work for grouping sets, since the output of the grouping sets
> aggregation may contains nulls not present before grouping.

> Probably that change should be undone and the comment expanded to
> explain why it isn't safe when the query has grouping sets.

Hm, I'm a bit hesitant to potentially noticeably regress plans here,
although it seems unikely that already "relies" on this. Can't we
essentially treat references to columns which can be set to null by due
to a grouping set, as containing an agg clause and only prevent moving
in that case?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2016-01-16 15:27:02 Re: BUG #13870: couldn't restore dump with mat view
Previous Message Michael Paquier 2016-01-16 13:07:37 Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby