On 08/07/16 10:59, Simon Riggs wrote:
On 8 July 2016 at 03:55, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote:> One of my examples was full text search and it does have > DDL, but that was an anti-example; all the feedback I have is that it was > much easier to use before it had DDL and that forcing it to use DDL pretty > much killed it for most users. That's just unsupported FUD. No, its me relaying opinions I have heard back to this list, for the purposes of understanding them. ("Fear, Uncertainty and Doubt" or FUD is doesn't apply here, unless its meant in the same way as "that's rubbish, I disagree".) I would say that most of the problems we've had with text search DDL came from the fact that previously people had done things in other ways and transitioning was hard. That experience doesn't make me want to repeat it; but building a feature that's supposed to be managed by direct catalog updates is precisely repeating that mistake. I'm okay with things like replication configuration being managed outside the system catalogs entirely (as indeed they are now). But if a feature has a catalog, it should have DDL to manipulate the catalog. It's a good rule. In this case all it does is move the discussion to "should it have a catalog?".
I think it should have catalog for most things. Otherwise it will be really hard to track mapping of tables to replication sets, etc. We'd have to invent mechanism of tracking dependencies outside of catalog, which is not endeavor that I want to go through. The feature is complex enough without this. Which means there should be DDL for those things as well. So the work I am doing now is based on this assumption. The DDL versus function from the point of implementation means tons of additional boilerplate code but it's not complex thing to do.
One interesting thing will be making sure we can replicate from physical standby in the future as you mentioned elsewhere in the thread but I think that should be possible as long as you define the catalogs on master (not really sure yet if there are any barriers or not).
About the pg_dump support. While I don't think we'll necessarily want to dump all the information related to logical replication (like subscriptions), I definitely think we should dump replication sets and their membership info for example.
-- 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
