Re: Proposal: GiST constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: GiST constraints
Date: 2008-06-10 01:00:05
Message-ID: 4414.1213059605@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-06-10 01:25:17 Re: Core team statement on replication in PostgreSQL
Previous Message Alvaro Herrera 2008-06-10 00:37:19 Re: pg_dump restore time and Foreign Keys