On Saturday, July 7, 2018, Brent Kerby <blke...@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.
