"Hillel" <hillel 'at' ecommunicate.biz> writes: > Hi, > > If the table has bar, baz set as the primary key it will only delete once. > In our case you should make smsc,ts the primary key. This also then has the
This is not an option - my message implied that there can be multiple rows with a unique combination of smsc,ts. [...] > Another option is to use a serial column as it works well as shown below and > then we have replaced the previous Automatic OIDs with a sequential id. As far as I can tell, that's what you denied doing in: http://www.kannel.org/pipermail/devel/2008-June/001764.html (although it seems to me that it doesn't relate to the configuration). It seems that it is also the opinion of Stipe, although I cannot be sure: http://www.kannel.org/pipermail/devel/2008-June/001767.html although that's the cleanest solution, in my humble opinion - other than creating tables WITH OIDS as I suggested here: http://www.kannel.org/pipermail/devel/2008-June/001770.html which no one answered, by the way. At that point in the discussion, I find my patch with 'ctid' to be a better solution, if WITH OIDS and using a SERIAL column are ruled out. It's the closest implementation to the current one using oid's. > OIDs are a scarce resource, and if you run low on them it all goes horribly > wrong as OIDs are used for all sorts of stuff internal to the database, so > if you use them all up on user tables it can cause problems. Do you have pointers to support that claim? I can find none on pg's site. -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
