Re: WIP: Deferrable unique constraints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Deferrable unique constraints
Date
Msg-id 12652.1248714857@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Deferrable unique constraints  (Dean Rasheed <dean.a.rasheed@googlemail.com>)
Responses Re: WIP: Deferrable unique constraints
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@googlemail.com> writes:
> [ latest deferrable-unique patch ]

I'm starting to look at this now.  I haven't read the patch itself yet,
but I went through the discussion thread.  I'm not sure whether we have
actually decided that we want to commit this, as opposed to treating it
as an investigation exercise.

The main thing that is bothering me is something Dean pointed out at
the very beginning: the patch will not scale well for large numbers of
conflicts.  The reason this bothers me is that from what I recall of
past complaints about our lack of deferred unique checks, the *primary*
use case is things like "update foo set id = id + 1".  So I'm afraid
that this might be a toy implementation that's not useful in practice.

The three likely responses to this objection seem to be
1. "You're right, we should reject the patch until that's fixed."
2. "You're wrong, the patch is perfectly useful as-is."
3. "You're right, but we should commit anyway because it will be fixed  later."
I don't think I'm going to believe #3 though, because there's no
concrete design for a fix on the table, much less a commitment to
implement it.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: support empty string as separator for string_to_array
Next
From: Merlin Moncure
Date:
Subject: Re: proposal: support empty string as separator for string_to_array