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