Re: A Modest Upgrade Proposal

On 8 July 2016 at 11:18, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> Tom Lane wrote:
> > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>
> > > 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.
>
> Note that the alternative to DDL-based replication handling is not
> INSERT INTO pg_replication, but a function-based interface such as
> SELECT pg_replication_node_create(foo, bar); so there's no need to
> hardcode catalog definitions; nor there is a need to skip backup-ability
> of logical replication config: pg_dump support can be added by having it
> output function calls -- not catalog INSERTs!
>

Yeah. Direct DDL on the catalogs is crazy-talk, I can't imagine anyone
seriously suggesting that as an alternative. The only ways ahead are a
function-based interface or DDL.

Personally I strongly favour function-based for this. With named parameters
and default parameters it's nicely readable and self-documenting, so I
don't really buy the usability argument. You get slightly better output
from \h for DDL than from \df for a function, but only marginally, and
that's about it. Now, if we find that there are areas where a function
based interface is actually limiting, sure, lets use DDL. But not just for
the sake of DDL.

Note that you can implement a function based version in extensions for
older versions. This matters for logical replication because one of the
major appeals of it is up-version migration. If we rely on a bunch of new
DDL there isn't going to be a sane way to implement the decoding upstream
side in a way that'll work for connecting to old versions where the output
plugin has been backported as an extension.

Take pg_dump. Can you imagine pg_dump not supporting dumping from older
versions? Well, why should we not try to make it easy and practical to
stream from older versions?

Now, if the consensus here is that "we" don't care about supporting
decoding from the versions of Pg people actually use in the wild and making
it easier for them to move up to newer ones, well, that's why pglogical was
done as an extension. It'll be hard to get enthusiastic about some
re-imagined logical replication in-core that does much less than pglogical
for fewer target versions and fewer use cases though. Especially since "we
should use DDL" seems to have stayed at the hand-waving stage so far, with
no concrete proposals for what that DDL should look like and why it's
better.

The only difference between DDL and no DDL is that a function-based
> interface can be added with a few pg_proc.h entries, whereas the DDL
> stuff requires gram.y additions, new nodes, etc.
>

... and unlike DDL, a function based interface can be exposed for older
versions by extensions.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services