Re: Support EXCEPT for TABLES IN SCHEMA publications

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Date: 2026-07-14 09:34:51
Message-ID: CAJpy0uCFCdL97L3Pt8f586br5irqkzCa_i3tXMjH6JFCPxxr4Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Few comments for 002:

1)
@@ -210,9 +269,16 @@ ObjectsInPublicationToOids(List *pubobjspec_list,
ParseState *pstate,
break;
case PUBLICATIONOBJ_TABLES_IN_SCHEMA:
schemaid = get_namespace_oid(pubobj->name, false);
+ schema_name = pubobj->name;
+ schema_repeated = list_member_oid(*schemas, schemaid);

/* Filter out duplicates if user specifies "sch1, sch1" */
*schemas = list_append_unique_oid(*schemas, schemaid);
+
+ ProcessSchemaExceptTables(schemaid, schema_name,
+ pubobj->except_tables, pstate,
+ schema_repeated, &schemas_with_except,
+

Should we extract schema_name inside ProcessSchemaExceptTables, as we
are passing schemaid to it. Generally one such arguement should
suffice.

2)
We can also avoid passing 'schema_repeated' to function
ProcessSchemaExceptTables(). Instead we can pass input/output arg
'schemas' similar to 'schemas_with_except'. Let it extract 'repeated'
from schemas internally and also populate it internally with unique
schema-oid.

3)
ProcessSchemaExceptTables:

can we avoid repeated dereferences of eobj->pubtable->relation. We can
work with:
RangeVar *relation = eobj->pubtable->relation;

4)

+
+ if (except_tables != NIL)
+ *schemas_with_except = lappend_oid(*schemas_with_except, schemaid);

We can return early here:
if (except_tables == NIL)
return;

*schemas_with_except = lappend_oid(*schemas_with_except, schemaid);

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-07-14 09:45:11 Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk number 0 for toast value XXX
Previous Message Jonathan Gonzalez V. 2026-07-14 08:53:50 Re: Path Traversal Vulnerability in pg_dump Directory Format