Wed Mar 28 07:49:41 PDT 2007
- Previous message: Slony-generated primary keys (was Re: node ID limitations (was Re: [Slony1-general] Unexpected problems with Slony config))
- Next message: [Slony1-general] Re: node ID limitations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1658 Used gborg instead of pgfoundry since I don't see tickets on the later and no one else reponded. ~BAS On Wed, 28 Mar 2007, Csaba Nagy wrote: > 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. > > > _______________________________________________ > Slony1-general mailing list > Slony1-general at lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general > l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were."
- Previous message: Slony-generated primary keys (was Re: node ID limitations (was Re: [Slony1-general] Unexpected problems with Slony config))
- Next message: [Slony1-general] Re: node ID limitations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list