Re: Command Triggers

On Tue, Dec 13, 2011 at 8:25 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> There's another cautionary tale from the sepgsql history worth mentioning
> here, which surely I don't have to remind you about.  Making the goal for a
> first shippable subset include proof you can solve the hardest problems in
> that area can lead to a long road without committing anything.  With
> sepgsql, that was focusing on the worst of the ALTER TABLE issues.  As
> Dimitri was pointing out, the name change to Command Triggers includes a
> sort of admission that DDL Triggers are too hard to solve in all cases yet.
>  We shouldn't be as afraid to introduce APIs that are aimed at developers
> who currently have none.
>
> Yes, there's a risk that will end with "...and this one has to be broken in
> the next release because of this case we didn't see".

Well, the problem is that just because something better comes along
doesn't mean we'll actually deprecate and remove the old
functionality. We still have contrib/xml2, even though the docs say
we're "planning" to remove it in 8.4. Tom even rewrote the memory
handling, because it was easier to rewrite a module he probably
doesn't intrinsically care much about than to convince people we
should remove something that was both planned for deprecation anyway
and a huge security risk because it crashed if you looked at it
sideways. And we still have rules, so people read the documentation
and say to themselves "hmm, should i use triggers or rules for this
project?". And elsewhere we're discussing whether and under what
conditions it would be suitable to get rid of recovery.conf, which
almost everyone seems to agree is a poor design, largely AFAICT
because third-party tools find recovery.conf a convenient way to
circumvent the need to rewrite postgresql.conf, which is a pain in the
neck because of our insistence that it has to contain arbitrary user
comments. In other words, more often than not, we are extremely
reluctant to remove or modify features of even marginal utility
because there will certainly be somebody, somewhere who is relying on
the old behavior.

Of course, it does go the other way sometimes: we removed old-style
VACUUM FULL (which was useful if you were short of disk space and long
on time), flat-file authentication (which was used by third party
tools), and made removing OIDs require a table rewrite. Still, I
think it's entirely appropriate to be cautious about adding new
features that might not turn out to be the design we really want to
have. Odds are good that we will end up supporting them for backward
compatibility reasons for many, many years.

Now, all that having been said, I also agree that the perfect can be
the enemy of the good, and we go there frequently. The question I'm
asking is not whether the feature is perfect, but whether it's
adequate for even the most basic things people might want to do with
it. 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. In particular,
you won't have the index or constraint names, and you might not have
the schema or tablespace information either. But maybe we ought to
put the question to the intended audience for the feature - is there a
Slony developer in the house?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company