Re: Command Triggers - Mailing list pgsql-hackers

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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us