Re: Command Triggers

On 12/13/2011 09:59 AM, Robert Haas wrote:
> Well, the problem is that just because something better comes along
> doesn't mean we'll actually deprecate and remove the old
> functionality.

The examples you gave fall into three groups, and I think it's useful to
demarcate how they're different. Please pardon me going wildly off
topic before returning back.

If you drop xml2 or rules, people lose something. It's primarily the
PostgreSQL developers who gain something. You can make a case that
people who won't get sucked into doing something wrong with rules one
day will gain something, but those people are a future speculation;
they're not here asking to be saved for a problem they don't know will
happen yet. This sort of deprecation battle is nearly impossible to
win. One of the reasons I placed a small bet helping sponsor PGXN is
that I hope it allows some of this should be deprecated stuff to move
there usefully. Let the people who use it maintain it moving forward if
they feel it's important.

The recovery.conf change and other attempts to reorganize the
postgresql.conf are in a second category. These break scripts, without
providing an immediate and obvious gain to everyone. Some say it's
better, some say it's worse, from the list traffic it seems like a
zero-sum game. The burden is on the person advocating the change to
justify it if there's not a clear win for everyone. You might note that
my latest attitude toward this area is to provide the mechanism I want
as a new option, and not even try to argue about removing the old thing
anymore. This lets implementation ideas battle it out in the wild.
Let's say a year from now everyone who hasn't switched to using a conf.d
dirctory approach looks like an old stick in the mud. Then maybe I pull
the sheet I have an enormous bikeshed hidden behind, waiting for just
that day.[1]

When VACUUM FULL was rewritten, it took a recurring large problem that
has impacted a lot of people, and replaced with a much better thing for
most cases. A significantly smaller number of people lost something
that was slightly useful. There weren't as many complaints because the
thing that was lost was replaced with something better by most metrics.
Different, but better. This third category of changes are much easier
to sell. We have another such discontinuity coming with
pg_stat_activity. The changes Scott Mead's patch kicked off make it
different and better. Anyone who has a tool using the old thing can
look at the new design and say "well, that makes the whole 'what state
is the connection in' logic I used to worry about go away; that's
progress even if it breaks my old scripts". People need to get
something that offsets the breakage to keep griping down. Anyone who
argues against those sort of changes has a challenging battle on their
hands.

If there is a Command Trigger implementation that Slony etc. use, and we
discover a limitation that requires an API break, that's OK so long as
it's expected that will fall into the last category. Breakage to add
support for something new should be a feature clearly gained, something
lost, and with a net benefit to most consumers of that feature. People
accept it or block obvious forward progress. We don't want to get too
confused between what makes for good progress on that sort of thing with
the hard deprecation problems. (Not that I'm saying you are here, just
pointing out it happens)

> Dimitri says that he wants it so that we can add support for
> CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and
> Londiste. My fear is that it won't turn out to be adequate to that
> task, because there won't actually be enough information in the CREATE
> TABLE statement to do the same thing on all servers.

These are all good things to look into, please keep those test set ideas
coming and hopefully we'll get some more input on this. But let's say
this rolls out seeming good enough, and later someone discovers some
weird index thing that isn't supported. If that's followed by "here's a
new API; it breaks your old code, but it allows supporting that index
you couldn't deal with before", that's unlikely to get shot down by that
API's consumers. What you wouldn't be able to do is say "this new API
doesn't work right, let's just yank it out". Your concerns about making
sure at least the fundamentals hold here are on point though.

[1] Look at that, I can now say that 100% of the programs I compose
e-mail with now have "bikeshed" added to their dictionary. I don't
bother with this often, but there's entries for "PostgreSQL" and
"committer" there too.[2]

[2] Would you believe a Google search for "committer" shows the
PostgreSQL wiki page as its second hit? That's only behind the
Wikipedia link, and ahead of the FreeBSD, Chromium, Apache, and Mozilla
pages on that topic.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us