> > 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
