Re: adding partitioned tables to publications - Mailing list pgsql-hackers

From Amit Langote
Subject Re: adding partitioned tables to publications
Date
Msg-id CA+HiwqFBni-cXy5NBN0PdwxidXgcCEio0N_AOnOM0pR2dMWUyA@mail.gmail.com
Whole thread Raw
In response to Re: adding partitioned tables to publications  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: adding partitioned tables to publications  (Amit Langote <amitlangote09@gmail.com>)
Re: adding partitioned tables to publications  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi Peter,

On Mon, Mar 16, 2020 at 9:49 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> I was trying to extract some preparatory work from the remaining patches
> and came up with the attached.  This is part of your patch 0003, but
> also relevant for part 0004.  The problem was that COPY (SELECT *) is
> not sufficient when the table has generated columns, so we need to build
> the column list explicitly.
>
> Thoughts?

Thank you for that.

+   if (isnull || !remote_is_publishable)
+       ereport(ERROR,
+               (errmsg("table \"%s.%s\" on the publisher is not publishable",
+                       nspname, relname)));

Maybe add a one-line comment above this to say it's an "not supposed
to happen" error or am I missing something?  Wouldn't elog() suffice
for this?

Other than that, looks good.

--
Thank you,
Amit



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Small docs bugfix: make it clear what can be used in UPDATE FROM and DELETE USING
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager