Re: A Modest Upgrade Proposal - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: A Modest Upgrade Proposal |
Date | |
Msg-id | 10216.1467946517@sss.pgh.pa.us Whole thread Raw |
In response to | Re: A Modest Upgrade Proposal (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: A Modest Upgrade Proposal
(Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: A Modest Upgrade Proposal (Simon Riggs <simon@2ndquadrant.com>) |
List | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: > On 8 July 2016 at 02:41, Robert Haas <robertmhaas@gmail.com> wrote: >> DDL is our standard way of getting things into the system catalogs. >> We have no system catalog metadata that is intended to be populated by >> any means other than DDL. > pg_am has existed for decades without supporting DDL That argument has been obsoleted by events ;-) ... and in any case, the reason we went without CREATE ACCESS METHOD for so long was not that we encouraged "INSERT INTO pg_am" but that non-core index AMs were effectively unsupported anyway, until we thought of a reasonable way to let them generate WAL. Without the WAL stumbling block, I'm sure we would have built CREATE ACCESS METHOD long ago. It's just way too hard to deal with issues like cross-version changes otherwise. > and we have gone to > great lengths over many years to allow catalog tables to be > inserted/updated/deleted by normal SQL rather than DDL, so not all catalog > access is via DDL. But *all* of that is on "if you break it you get to keep both pieces" terms. In particular we do not promise the catalogs will remain stable across versions, so that inserts or updates on catalogs are very likely to break in new versions. I think that all such operations should be understood as emergency procedures, not recommended standard practice. > 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. 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. Direct SQL on a catalog should *never* become standard operating procedure. regards, tom lane
pgsql-hackers by date: