On 13/11/16 10:21, Andres Freund wrote: > On 2016-11-13 00:40:12 -0500, Peter Eisentraut wrote: >> On 11/12/16 2:18 PM, Andres Freund wrote: >>>>> 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). >> >> I'm not sure why that would be better. Adding catalog columns in future >> versions is not a problem. > > It can be extended from what core provides, for extended versions of > replication solutions, for one. I presume publications/subscriptions > aren't only going to be used by built-in code. >
I understand the desire here (especially as an author of such out of the core tools), but I am not sure if this is a good place where to start having pluggable catalogs given that we have no generic idea for those. Currently, plugins writing arbitrary data to catalogs will cause things to break when those plugins get uninstalled (and we don't have good mechanism for cleaning that up when that happens). And that won't change if we convert this into array. Besides, shouldn't the code then anyway check that we only have expected data in that array otherwise we might miss corruption? So if the main reason for turning this into array is extendability for other providers then I am -1 on the idea. IMHO this is for completely different path that adds user catalogs with proper syscache-like interface and everything but has nothing to do with publications. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers