Re: Event Triggers: adding information

On 2013-01-18 17:20:51 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> Well, that burden already exists for non-utility statements --- why
> >>> should utility statements get a pass? Other than that we tend to invent
> >>> new utility syntax freely, which might be a good thing to discourage
> >>> anyhow.
> >
> >> My concerns are that (1) it will slow down the addition of new
> >> features to PostgreSQL by adding yet another barrier to commit and (2)
> >> it won't be get enough use or regression test coverage to be, or
> >> remain, bug-free.
> >
> > Meh. The barriers to inventing new statements are already mighty tall.
> > As for (2), I agree there's risk of bugs, but what alternative have you
> > got that is likely to be less bug-prone? At least a reverse-list
> > capability could be tested standalone without having to set up a logical
> > replication configuration.
> >
> > This should not be interpreted as saying I'm gung-ho to do this, mind
> > you. I'm just saying that if our intention is to support logical
> > replication of all DDL operations, none of the alternatives look cheap.
>
> Well, we agree on that, anyway. :-)
>
> I honestly don't know what to do about this. I think you, Alvaro, and
> I all have roughly the same opinion of this, which is that it doesn't
> sound fun, but there's probably nothing better.

Count me in.

> So, what do we do
> when a really cool potential feature (logical replication of DDL)
> butts up against an expensive future maintenance requirement?

I just tried to estimate the effort of that by looking at:
git log REL9_1_0..REL9_2_0 src/backend/parser/gram.y src/include/nodes/
which seems like it would catch most such patches.

First thing I have to say is there are more patches potentially
affecting such a potential feature than I previously had thought.
On the other hand, just about all of those patches are so big that the
amount of changes to the ruleutils.c equivalent for DDL look like a
minor pain in comparison to the rest.

The patches that seemed relevant during 9.1=>9.2 seem to be to be the
following when counting ones that directly would add new deparsing code:
* NOT VALID
* SECURITY LABEL
* per column fdw options
* range datatypes
* security barrier
* LEAKPROOF
* privileges on types
* ALTER FDW
* rename domain constraints

Then there were a bunch of patches adding new features that required
restructuring of existing code that would have affected possible
deparsing code:
* plancache restructuring
* parametrized indexscans
* DROP ... consolidation

In all of those but "ALTER FDW" and "rename domain constraints" possible
deparsing code looks like it would be an absolutely minor part of the
code. And in those its only a relevant part because they are really
small.

There were some bugfixes that would have required touching it as well,
but those seemed to be cases that are basically s/a/b/.

Not sure what the consequence of that is, but I wanted to share it
anyway after spending the time ;).

> I'm not
> even sure what the criteria should be for making a decision on whether
> it's "worth it".

In my experience it is the weakest point in the non-WAL based postgres
replication tools. So I personally think it is worth some overhead when
adding new features.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services