On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> New version attached. It needs some of these problem cases added to
> the testing, and a mention in the docs that only C and plpgsql
> triggers can use the feature so far. I'll add those tomorrow.
Done and attached.
Now the question is, should it be pushed? It's been through just
about every CF in the last three years with little modification, and
finally got a thorough enough review in this CF that I think it can
be considered. Here are the numbers:
85 files changed, 2266 insertions(+), 132 deletions(-)
Of that, 70 lines are the plpgsql implementation (which I should
probably push separately), about 200 lines are docs and 623 lines
are new regression tests. Most of the rest only comes into play if
the feature is used.
This adds support for SQL standard sub-feature, although only in
triggers written in C and plpgsql. (Other PLs will probably require
fewer lines than plpgsql.) It also provides infrastructure needed
to get incremental maintenance of materialized views based on just
simple declarative DDL. Tom has expressed hope that it could be
used to improve performance and memory usage for AFTER triggers, and
I believe it can, but that that should be a follow-on patch. It
might provide the basis of set-based statement-level enforcement of
referential integrity, with the regression tests providing a rough
proof of concept.
My inclination is to push it late today, but be ready to revert if
there are any hard-to-fix surprise problems missed in review and
testing; but if the general preference is to hold it for version 11,
that's OK with me, too.
--
Kevin Grittner
