> 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?".
Let me return to my end point from last night: it's becoming clear that asking the question "DDL or not?" is too high level a thought and is leading to argument. The most likely answer is "some", but still not sure. I am looking at this in more detail and will return in a few days with a much more specific design that we can use to answer the question in detail.
Direct SQL on a catalog should *never* become standard operating procedure.
Agreed, but it has always been considered to be something we should consider when making DDL work.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
