Re: Transition relations: correlating OLD TABLE and NEW TABLE

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Brent Kerby <blkerby(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transition relations: correlating OLD TABLE and NEW TABLE
Date: 2018-07-07 15:16:57
Message-ID: CAKFQuwY-uZ4GRPa=EXfV5_HjuEdETL+B4Z9xzpO1KZkXKtXExw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, July 7, 2018, Brent Kerby <blkerby(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2018-07-07 15:20:51 Re: peripatus build failures....
Previous Message Tom Lane 2018-07-07 15:11:24 Re: peripatus build failures....