Re: [PATCH] Erase the distinctClause if the result is unique by definition

On Tue, Feb 11, 2020 at 3:56 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> >
> > and if we prepare sql outside a transaction, and execute it in the
> > transaction, the other session can't drop the constraint until the
> > transaction is ended.
>
> And what if you create a view on top of a query containing a distinct
> clause
> rather than using prepared statements? FWIW your patch doesn't handle such
> case at all, without even needing to drop constraints:
>
> CREATE TABLE t (a int primary key, b int not null, c int);
> INSERT INTO t VALUEs(1, 1, 1), (2, 2, 2);
> CREATE UNIQUE INDEX t_idx1 on t(b);
> CREATE VIEW v1 AS SELECT DISTINCT b FROM t;
> EXPLAIN SELECT * FROM v1;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>
>
This error can be fixed with

- num_of_rtables = bms_num_members(non_semi_anti_relids);
+ num_of_rtables = list_length(query->rtable);

This test case also be added into the patch.

> I also think this is not the right way to handle this optimization.
>

do you have any other concerns?