> > I think that the ONLY was wrong from day one :-( > > Well, sure, but until we have an implementation that actually > *works* across multiple tables, it has to be there so that we > can at least consistently support the current single-table > semantics. Until we have some form of cross-table unique > constraint (index or whatever) we can't support multi-table > foreign keys
> --- taking off the ONLY is not a fix. Um, I think it would work for a special case, where the unique constraint includes the partitioning column[s], and the partitions (check constraints) don't overlap. In this case you can create simple unique indexes on the subtables. When looking at other db's this is not such an exceptional requirement for unique indexes that share the same partitioning scheme as the table. And imho the "all indexes sharing the table partitioning scheme" is the most important use case. Andreas ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
