Re: Postgres-R: primary key patches

Hi,

chris wrote:
> I agree with you that tables are *supposed* to have primary keys;
> that's proper design, and if tables are missing them, then something
> is definitely broken.

Ah, I see, so you are not concerned about tables with a PRIMARY KEY for 
which one wants another REPLICATION KEY, but only about tables without a 
PRIMARY KEY, for which one doesn't want a PRIMARY KEY in the first place.

However, that's a general limitation of replication at tuple level: you 
need to be able to uniquely identify tuples. (Unlike replication on 
storage level, which can use the storage location for that).

> Sometimes, unfortunately, people make errors in design, and we wind up
> needing to accomodate situations that are "less than perfect."
> 
> The "happy happenstance" is that, in modern versions of PostgreSQL, a
> unique index may be added in the background so that this may be
> rectified without outage if you can live with a "candidate primary
> key" rather than a true PRIMARY KEY.

I cannot see any reason for not wanting a PRIMARY KEY, but wanting 
replication, and therefore a REPLICATION KEY.

Or are you saying we should add a hidden REPLICATION KEY for people who 
are afraid of schema changes and dislike a visible primary key? Would 
you want to hide the underlying index as well?

> It seems to me that this extension can cover over a number of "design
> sins," which looks like a very kind accomodation where it is surely
> preferable to design it in earlier rather than later.

Sorry, but I fail to see any real advantage of that covering of "sins". 
I would find it rather confusing to have keys and indices hidden from 
the admin. It's not like an additional index or a primary key would lead 
to functional changes.

That's certainly different for additional columns, where a SELECT * 
could all of a sudden return more columns than before. So that's the 
exception where I agree that hiding such an additional column like we 
already do for system columns would make sense. That's for example the 
situation where you add an 'id' column later on and make that the new 
primary (and thus replication) key. Maybe that's what you meant? 
However, even in that case, I wouldn't hide the index nor the primary 
key, but only the column.

Regards

Markus