Logical Replication - revisit `is_table_publication` function implementation

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Logical Replication - revisit `is_table_publication` function implementation
Date: 2026-04-07 07:02:23
Message-ID: CAHut+Pti83yGaV5-DZU=AvJHxFDuoKW8_pjSedRham8SgZxLYA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, after confirming my understanding of pg_publication_rel [1], I
revisited some logical replication internal functions.

Specifically.
* The `is_table_publication` function is for checking if the
publication has a clause like "FOR TABLE t1".
* The `is_schema_publication` function is for checking if the
publication has a clause like "FOR TABLES IN SCHEMA s1".

Notice that neither of these ("FOR TABLE", "FOR TABLES IN SCHEMA")
clauses are possible simultaneously with "FOR ALL TABLES".

And we can readily discover if "FOR ALL TABLES" (aka `puballtables`)
is present from the pubform.

We can use this to optimise and simplify the implementations of the
`is_schema_publication` and `is_table_publication` functions.

PSA patch v1.

AFAICT, the result is:
- less code + simpler logic. e.g. is_table_publication does not check
'prexcept' anymore
- more efficient. e.g. skips unnecessary scanning when puballtables is true.
- more consistent. e.g., both functions are now almost identical.

Thoughts?

======
[1] https://www.postgresql.org/message-id/flat/CAHut%2BPv1UKR_bxmN7wcCCpQveHoYprvH-hbdFq8gsaH1Ye7B_w%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment Content-Type Size
v1-0001-rewrite-is_table_publication.patch application/octet-stream 5.1 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2026-04-07 07:04:51 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message John Naylor 2026-04-07 06:51:35 Re: [PATCH] Simplify SortSupport implementation for macaddr