Re: Restrict publishing of partitioned table with a foreign table as partition

On Tue, 4 Feb 2025 at 21:21, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2025-Feb-04, vignesh C wrote:
>
> > We should throw an error for partitioned tables that contain foreign
> > partitions, as this would include the data from these foreign tables
> > during the initial sync, while incremental changes would not be
> > replicated.
>
> Hmm, I would support the idea of allowing partitioned tables containing
> foreign partitions into publications, where only the tuples in
> non-foreign partitions would be transmitted -- both during initial sync
> and during replicated DML. This way, any partitioned tables with mixed
> local and foreign partitions would work okay for replication. If the
> subscriber wants the data in the foreign partitions, they can create the
> foreign table on the subscription side and all is well. From a users
> POV this is probably the most useful.
>
> Another aspect is the case where you create the publication first and
> the foreign table later. I didn't spot in the proposed patch any code
> that would check whether a publication including this schema exists,
> which we would have to do if we wanted to be watertight about rejecting
> publications with foreign tables. But I think that would be a bad
> direction to go it.
>
> I'd rather have the table-listing code for publications skip any foreign
> tables. For instance, GetPubPartitionOptionRelations() and
> PublicationAddTables() should skip tables with relkind RELKIND_FOREIGN.
> The sync code should also silently ignore all foreign tables.

We can maintain the behavior you suggested when the
PUBLISH_VIA_PARTITION_ROOT option is set to false. However, when
PUBLISH_VIA_PARTITION_ROOT is true, the table data is copied from the
root table (as intended by the user), which will also include the
foreign table data. In this case, wouldn’t it be better to throw an
error?

Regards,
Vignesh