On Tue, Feb 11, 2020 at 3:56 PM Julien Rouhaud <rjuju...@gmail.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?
0001-Erase-the-distinctClause-if-the-result-is-unique-by-.patch
Description: Binary data
