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
