Re: Transition relations: correlating OLD TABLE and NEW TABLE - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Transition relations: correlating OLD TABLE and NEW TABLE
Date
Msg-id CAKFQuwY-uZ4GRPa=EXfV5_HjuEdETL+B4Z9xzpO1KZkXKtXExw@mail.gmail.com
Whole thread Raw
In response to Re: Transition relations: correlating OLD TABLE and NEW TABLE  (Brent Kerby <blkerby@gmail.com>)
List pgsql-hackers
On Saturday, July 7, 2018, Brent Kerby <blkerby@gmail.com> wrote:
Also, there are cases where it may not be desired to have a primary key, as the index maintenance and constraint checking are not free and not always necessary.

Btree uniqueness enforcement is worth the price.
 
I'd be happy to try to work out an implementation of REFERENCING CHANGE TABLE if there's support for the idea. Or is there some problem with this, or some better way of achieving the goal?

I do see the value in basically saying, "I have a unique index but I want to write a generic function that can handle being installed on any table and, without dynamic sql, can be presented with a full outer join relation of all inserts, updates, and deletes."  Natural join won't work.  We can limit the feature to just transition tables or create a new join type that would require left and right to be the same relation and the syste, would figure out and join on the PK columns (or planner error if there are none).

Keep in mind that part of this discussion involves deciding where we are OK with being non-standard.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: peripatus build failures....
Next
From: Larry Rosenman
Date:
Subject: Re: peripatus build failures....