| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: propagating replica identity to partitions | 
| Date: | 2019-03-22 18:55:11 | 
| Message-ID: | 806fd173-9084-5fb8-ed78-25398ab9e92f@2ndquadrant.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2019-03-22 17:52, Alvaro Herrera wrote:
> To recap: my proposed change is to make
>     ALTER TABLE ... REPLICA IDENTITY
> when applied on a partitioned table affect all of its partitions instead
> of expecting the user to invoke the command for each partition.
If you are operating on a partitioned table and set the replica identity
to the primary key or a partitioned index of that partitioned table,
then I think, by definition of what it means to be a partitioned index,
that applies to the whole partition hierarchy.
Aside from that theoretical consideration, what would be the practical
use of not doing that?
> At the
> same time, I am proposing not to change to have recursive behavior other
> forms of ALTER TABLE in one commit, such as TABLESPACE and OWNER TO,
> which currently do not have recursive behavior.
I'm slightly baffled that we would even allow having different owners on
different partitions, but that seems to be a separate discussion.
In general, it seems sensible that if you operate on a partitioned
table, the whole partition hierarchy is affected unless told otherwise.
There may be sensible exceptions, but it seems useful as the default.
-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabrízio de Royes Mello | 2019-03-22 19:49:57 | Introduce MIN/MAX aggregate functions to pg_lsn | 
| Previous Message | Andres Freund | 2019-03-22 18:33:05 | Re: shared-memory based stats collector |