Re: logical changeset generation v3 - comparison to Postgres-R change set format

Hannu Krosing <hannu@2ndquadrant.com>

From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Markus Wanner <markus@bluegap.ch>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2012-11-17T14:57:39Z
Lists: pgsql-hackers
On 11/17/2012 03:00 PM, Markus Wanner wrote:
> On 11/17/2012 02:30 PM, Hannu Krosing wrote:
>> Is it possible to replicate UPDATEs and DELETEs without a primary key in
>> PostgreSQL-R
> No. There must be some way to logically identify the tuple. Note,
> though, that theoretically any (unconditional) unique key would suffice.
> In practice, that usually doesn't matter, as you rarely have one or more
> unique keys without a primary.
...
> Are there other reasons to want tables without primary keys that I'm
> missing?
>
Nope. The only place a table without a primary key would be needed is a 
log table, but as these are (supposed to be) INSERT-only this is not a 
problem for them.

Hannu


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Background worker processes

  2. Rearrange storage of data in xl_running_xacts.

  3. Basic binary heap implementation.

  4. Embedded list interface

  5. Refactor xlog.c to create src/backend/postmaster/startup.c