Hi all,

> > Considering that people seem to agree that slony generated pkeys are
> > more of a wart than a feature, why not simply deprecate the feature
> > and remove it?
> 
> I tend to lean that way, since I've been making it a point to ensure that
> all our tables have primary keys.  I believe it's not a big deal to
> create them for Slony if they don't exist, and I'd rather intelligently
> select a primary key than have Slony add an "arbitrary" bigint field.
> Removing that capability would certainly simply the slony code.
> 
> However, I'm hoping to come up with an improvement that the community will
> accept so it goes back into the tree.  My thought is that the capability
> wouldn't be there if people weren't using it, so yanking it could cause
> some upset.

We do use here this feature (letting slony add the "arbitrary" PKs). 
It has a couple of advantages over maintaining it in our own schema.

There are tables where having a PK simply does NOT make sense. Most of
our tables do have PKs, and I fitted some of them which did not have
with new ones specifically after we started to use slony (I even had to
split tables in different sub-tables for this, but it was actually
making sense), but there are a couple where I simply couldn't justify
adding a PK...

This combined with the fact that not all our data bases are replicated
via slony but they share the same schema results in me being happy if
slony takes care of adding the PK which is totally irrelevant to our
application and it only suits slony... with the added benefit that it
gets deleted once slony is uninstalled from the DB.

Now if slony will not do that anymore on its own, it could be
acceptable, if only there would be some nice GUI admin interface which I
can tell "please replicate all my tables and do whatever it is needed to
do so"... and get some warnings if there are BLOBs, missing PKs, etc.
(yes I know about pgadmin and I'm using it but it's not really working
well if you have 200 tables to replicate).

Cheers,
Csaba.