"David Fetter" <david@fetter.org> writes:
> On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote:
>> Hello Chris,
>>
>> chris wrote:
>>> Slony-I does the same, with the "variation" that it permits the
>>> option of using a "candidate primary key," namely an index that is
>>> unique+NOT NULL.
>>>
>>> If it is possible to support that broader notion, that might make
>>> addition of these sorts of logic more widely useful.
>>
>> Well, yeah, that's technically not much different, so it would
>> probably be very easy to extend Postgres-R to work on any arbitrary
>> Index.
>>
>> But what do we have primary keys for, in the first place? Isn't it
>> exactly the *primay* key into the table, which you want to use for
>> replication? Or do we need an additional per-table configuration
>> option for that? A REPLICATION KEY besides the PRIMARY KEY?
Hm, it occurs to me that really Slony should be saying WHERE (col1,col2,...) = ('x','y','z',...)
and letting the server figure out what access method is best for finding the
candidate record. That could mean using the primary key index, or it could
mean using some other index (perhaps a partial index for example).
It would be nice if there was a way for Slony to express to the server that
really, it only needs any UNIQUE NOT NULL combination of columns to match.
Once the server has any such combination which matches it can skip checking
the rest. I can't think of any way to write such a query in SQL.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
