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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
