From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | Steve Singer <steve(at)ssinger(dot)info>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logical Replication WIP |
Date: | 2016-11-12 19:18:25 |
Message-ID: | 20161112191825.q3zmdr5cmchwxdz4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-11-11 12:04:27 +0100, Petr Jelinek wrote:
> On 04/11/16 14:00, Andres Freund wrote:
> > Hi,
> >
> > + <sect1 id="catalog-pg-publication-rel">
> > + <title><structname>pg_publication_rel</structname></title>
> > +
> > + <indexterm zone="catalog-pg-publication-rel">
> > + <primary>pg_publication_rel</primary>
> > + </indexterm>
> > +
> > + <para>
> > + The <structname>pg_publication_rel</structname> catalog contains
> > + mapping between tables and publications in the database. This is many to
> > + many mapping.
> > + </para>
> >
> > I wonder if we shouldn't abstract this a bit away from relations to
> > allow other objects to be exported to. Could structure it a bit more
> > like pg_depend.
> >
>
> Honestly, let's not overdesign this. Change like that can be made in the
> future if we need it and I am quite unconvinced we do given that
> anything we might want to replicate will be relation. I understand that
> it might be useful to know what's on downstream in terms of objects at
> some point for some future functionality, but I am don't have idea how
> that functionality will look like so it's premature to guess what
> catalog structure it will need.
I slightly prefer to make it more generic right now, but I don't think
that's a blocker.
> > I still would very much like to move this outside of gram.y and just use
> > IDENTs here. Like how COPY options are handled.
> >
>
> Well, I looked into it and it means some loss of info in the error
> messages - mainly the error position in the query because utility
> statements don't get ParseState (unlike COPY). It might be worth the
> flexibility though.
Pretty sure that that's the case.
> > I also wonder if we want an easier to
> > extend form of pubinsert/update/delete (say to add pubddl, pubtruncate,
> > pub ... without changing the schema).
> >
>
> So like, text array that's then parsed everywhere (I am not doing
> bitmask/int definitely)?
Yes, that sounds good to me. Then convert it to individual booleans or a
bitmask when loading the publications into the in-memory form (which you
already do).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-11-12 19:19:03 | Re: Logical Replication WIP |
Previous Message | Andres Freund | 2016-11-12 19:12:57 | Re: PATCH: two slab-like memory allocators |