> On Mon, 2008-06-09 at 13:28 -0400, Tom Lane wrote:
>> I would like to see something that replaces the current btree-only kluge
>> for UNIQUE, if we're going to try to do something "general". IOW, don't
>> think of this as GiST-specific.
> I'm not sure exactly what you have in mind when you say "kludge".
Well, there are at least three things not to like about the btree UNIQUE
implementation:
1. It's btree-specific and can't be shared by other index AMs that might
wish to implement constraints.
2. It involves the index AM reaching into the heap, which is at the
least a serious failure of modularity.
3. There's no way to implement a deferred uniqueness check, nor even to
handle the within-statement conflict problem.
It looks to me like the same knocks can be laid on your proposal.
Now admittedly I don't have a solution that addresses these objections
(much less one that does it without losing any performance) but I'm
hesitant to see us building new features in this area without any idea
how we will fix these things --- especially #3, which is a SQL-spec
violation as well as a frequent user complaint. I'd like to have at
least a design plan for fixing these things, so we know whether we are
painting ourselves (further) into a corner.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment