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