On Saturday, July 7, 2018, Brent Kerby 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
This is a possible workaround. But even if a table has a primary key, it
seems like there's some inefficiency in doing things this way: the old and
new row versions start out linked together (for instance this information
is available in a FOR EACH ROW trigger), but we're throwing away that
informa
On Friday, July 6, 2018, Brent Kerby wrote:
> Of course if the table has a primary key, then this can be used, but I'm
> wondering how to handle this in the general case where a primary key might
> not exist.
>
Personally, I would consider the lack of a PK a rare and special case...I'd
handle th
