From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, David Fetter <david(at)fetter(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Deferrable unique constraints |
Date: | 2009-07-27 17:14:17 |
Message-ID: | 12652.1248714857@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-07-27 17:28:29 | Re: proposal: support empty string as separator for string_to_array |
Previous Message | Pavel Stehule | 2009-07-27 17:03:49 | Re: proposal: support empty string as separator for string_to_array |