Re: A Modest Upgrade Proposal - Mailing list pgsql-hackers
| From | Simon Riggs |
|---|---|
| Subject | Re: A Modest Upgrade Proposal |
| Date | |
| Msg-id | CANP8+jKH2x25ABoZ8hudt3h7iOT0xVq2CJbHRY9ws-gpB=mcfA@mail.gmail.com Whole thread Raw |
| In response to | Re: A Modest Upgrade Proposal (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: A Modest Upgrade Proposal
|
| List | pgsql-hackers |
On 7 July 2016 at 21:01, Robert Haas <robertmhaas@gmail.com> wrote:
--
On Mon, May 16, 2016 at 9:22 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> David Fetter wrote:
>> As a relatively (to our users) minor course correction, I would like
>> to propose the following:
>
>> - Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
>> replication that's already in large part built.
>>
>> This path would, of course, run either locally or across a network,
>> and be testable in both cases.
>
> This is one use case that pglogical intends to fulfill. If you're able
> to contribute to that project, I'm sure many would appreciate it. Right
> now the hottest question seems to be: is this something that should be
> an extension, or should it be part of core with its own set of DDL etc?
> The current patch is geared towards the former, so if the community at
> large prefers to have it as the latter and would oppose the former, now
> is the time to speak up so that the course can be corrected.
There was an unconference session on this topic at PGCon and quite a
number of people there stated that they found DDL to be an ease-of-use
feature and wanted to have it.
Yes, I ran the unconference session. It was a shame you weren't able to stay for the whole discussion.
We all agreed that an in-core solution was desirable, if only for wider adoption.
About half the people wanted DDL and about half the people didn't. When we discussed why we wanted DDL there wasn't any answers apart from the thought that we want to be able to backup the replication configurations, which seemed to be possible with or without DDL. Any such backup would need to be easily removed from the objects themselves, to avoid external dependencies on making recovery work.
Chris Browne finally summed it up by saying we could wait on having DDL until some time later, once we've decided on things like how we configure it, how we secure it and what/how to store it in the catalog. "We could probably live without DDL in the first version."
Personally, I'm in the group of people that don't see the need for DDL. There are already many successful features that don't utilize DDL, such as backup, advisory locks and some features that use DDL that don't really need to such as LISTEN/NOTIFY, full text search etc.. Also note that both Oracle and SQLServer have moved away from DDL in favour of function APIs, most NoSQL databases and almost all languages prefer functional interfaces over parsed text languages, so I don't see a huge industry revival for DDL as means of specifying things.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: