Re: A Modest Upgrade Proposal
| От | Craig Ringer |
|---|---|
| Тема | Re: A Modest Upgrade Proposal |
| Дата | |
| Msg-id | CAMsr+YGEQXxMX9ta0WBcn-ms8=MMmASLykt0CqSNwfE8OhWA7w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: A Modest Upgrade Proposal (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Список | pgsql-hackers |
On 8 July 2016 at 11:18, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Michael PaquierДата:
Сообщение: Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby