On 8 July 2016 at 03:55, Tom Lane <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?".

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

Reply via email to