| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, Steve Singer <steve(at)ssinger(dot)info> |
| Subject: | Re: Logical Replication WIP |
| Date: | 2016-09-28 13:12:19 |
| Message-ID: | 28681a48-8366-4343-3bf4-5381385c2f40@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/23/16 9:28 PM, Petr Jelinek wrote:
>> Document to what extent other relation types are supported (e.g.,
>> > materialized views as source, view or foreign table or temp table as
>> > target). Suggest an updatable view as target if user wants to have
>> > different table names or write into a different table structure.
>> >
> I don't think that's good suggestion, for one it won't work for UPDATEs
> as we have completely different path for finding the tuple to update
> which only works on real data, not on view. I am thinking of even just
> allowing table to table replication in v1 tbh, but yes it should be
> documented what target relation types can be.
I'll generalize this then to: Determine which relation types should be
supported at either end, document that, and then make sure it works that
way. A restrictive implementation is OK for the first version, as long
as it keeps options open.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-09-28 13:14:41 | Re: psql casts aspersions on server reliability |
| Previous Message | Lou Picciano | 2016-09-28 13:11:50 | Python3.4 detection on 9.6 configuration |