On 10/15/2013 11:38 AM, Peter Geoghegan wrote:
> We thought about prioritizing where to look (mostly as a performance
> optimization), but right now no. It works with amcanunique methods,
> which in practice means btrees. There is no such thing as a GiST
> unique index, so I guess you're referring to an exclusion constraint
> on an equality operator. That doesn't work with this, but why would
> you want it to? As for generalizing this to work with exclusion
> constraints, which I guess you might have also meant, that's a much
> more difficult and much less compelling proposition, in my opinion.
Yeah, that was one thing I was thinking of.
Also, because you can't INDEX CONCURRENTLY a PK, I've been building a
lot of databases which have no PKs, only UNIQUE indexes. Historically,
this hasn't been an issue because aside from wonky annoyances (like the
CONCURRENTLY case), Postgres doesn't distinguish between UNIQUE indexes
and PRIMARY KEYs -- as, indeed, it shouldn't, since they're both keys,
adn the whole concept of a "primary key" is a legacy of index-organized
databases, which PostgreSQL is not.
However, it does seem like the new syntax could be extended with and
optional "USING unqiue_index_name" in the future (9.5), no?
I'm just checking that we're not painting ourselves into a corner with
this particular implementation. It's OK if it doesn't implement most
things now; it's bad if it is impossible to build on and we have to
support it forever.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com