On Fri, Sep 11, 2026 at 5:22 PM Amit Kapila <[email protected]> wrote: > > On Fri, Sep 11, 2026 at 12:34 PM Peter Smith <[email protected]> wrote: > > > > In my earlier example, there are both precept t and f. > > > > Won't your v4 new function return a random *isexcept result based on > > the first one it stumbles upon? > > > > Yes, but how does that matter? We just don't want the operation to > proceed when the table is part of publication, users anyway need to > fix it before proceeding. >
OTOH it doesn't matter because they are both problems the user must fix. But won't it be better to get a consistent/deterministic error message for the same problem? e.g.1 test_pub=# CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT (TABLE t1); CREATE PUBLICATION test_pub=# CREATE PUBLICATION pub2 FOR TABLE t1; CREATE PUBLICATION test_pub=# select * from pg_publication_rel; oid | prpubid | prrelid | prexcept | prqual | prattrs -------+---------+---------+----------+--------+--------- 16392 | 16391 | 16387 | t | | 16394 | 16393 | 16387 | f | | (2 rows) e.g.2 test_pub=# DROP publication pub1; DROP PUBLICATION test_pub=# DROP publication pub2; DROP PUBLICATION test_pub=# CREATE PUBLICATION pub2 FOR TABLE t1; CREATE PUBLICATION test_pub=# CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT (TABLE t1); CREATE PUBLICATION test_pub=# select * from pg_publication_rel; oid | prpubid | prrelid | prexcept | prqual | prattrs -------+---------+---------+----------+--------+--------- 16396 | 16395 | 16387 | f | | 16398 | 16397 | 16387 | t | | (2 rows) Everything there is identical. Same pub names, same table exclsions/inclusions etc. But the order of operations is different, so the order of pg_publication_rel entries is different, so the *isexcept returned from that function is different, so the user sees 2 different error messages for the same problem. That just seemed a bit strange to me. Won't that kind of non-determinism also potentially break BF? ====== Kind Regards, Peter Smith. Fujitsu Australia
