Re: A Modest Upgrade Proposal

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A Modest Upgrade Proposal
Date: 2016-07-07 23:15:19
Message-ID: CANP8+jKH2x25ABoZ8hudt3h7iOT0xVq2CJbHRY9ws-gpB=mcfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7 July 2016 at 21:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, May 16, 2016 at 9:22 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-07-07 23:18:28 Re: A Modest Upgrade Proposal
Previous Message Tom Lane 2016-07-07 22:53:33 Re: SELECT DISTINCT never uses an index?