On 08/07/16 10:59, Simon Riggs wrote:
On 8 July 2016 at 03:55, Tom Lane <t...@sss.pgh.pa.us
> 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
to be managed by direct catalog updates is precisely repeating that
I'm okay with things like replication configuration being managed
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 (firstname.lastname@example.org)
To make changes to your subscription: