Jeff Davis writes:
> Currently, the check for exclusion constraints performs a sanity check
> that's slightly too strict -- it assumes that a tuple will conflict with
> itself. That is not always the case: the operator might be "<>", in
> which case it's perfectly valid for the search for conflict
Robert Haas writes:
> ... The fact that not very many people will want to do
> something is not a reason to prevent it.
It's not about preventing it for no reason. The proposed patch removes a
significant sanity check from code that still hasn't gotten out of beta.
I might be willing to remove i
On Sun, May 30, 2010 at 10:01 AM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2010-05-30 06:55 +0300, Robert Haas wrote:
>>> I've often wished for the ability to constrain a tale to hold just one
>>> row, so I don't find that use case implausible at all.
>
>> As I pointed out in
>> http://arch
Marko Tiikkaja writes:
> On 2010-05-30 06:55 +0300, Robert Haas wrote:
>> I've often wished for the ability to constrain a tale to hold just one
>> row, so I don't find that use case implausible at all.
> As I pointed out in
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01177.php , yo
On 2010-05-30 06:55 +0300, Robert Haas wrote:
> On Sat, May 29, 2010 at 11:40 PM, Tom Lane wrote:
>> Yes, I've seen Jeff's example. It's a cute hack but somehow I doubt
>> that there is going to be a land rush to implement such things.
>> Can you point to any pre-existing example where anyone act
On Sat, May 29, 2010 at 11:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
>>> Or, to put it differently: if nobody's done that in the past twenty
>>> years, why is it likely to happen before 9.1?
>
>> Hmm. Well suppose we bet a dollar on whether
Robert Haas writes:
> On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
>> Or, to put it differently: if nobody's done that in the past twenty
>> years, why is it likely to happen before 9.1?
> Hmm. Well suppose we bet a dollar on whether that will happen or not.
> In fact, if you promise not t
On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> The only disadvantage I see of just documenting this is that someone
>> might write a user-defined index opclass that works like this, and
>> they won't be able to use this until at least 9.1 (or at least, not
>> without pa
On Sat, May 29, 2010 at 06:11:57PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > The only disadvantage I see of just documenting this is that
> > someone might write a user-defined index opclass that works like
> > this, and they won't be able to use this until at least 9.1 (or at
> > least, no
Robert Haas writes:
> The only disadvantage I see of just documenting this is that someone
> might write a user-defined index opclass that works like this, and
> they won't be able to use this until at least 9.1 (or at least, not
> without patching the source).
I don't actually think that anyone'
On Fri, May 28, 2010 at 10:32 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Jeff Davis writes:
>> > Currently, the check for exclusion constraints performs a sanity check
>> > that's slightly too strict -- it assumes that a tuple will conflict with
>> > itself. That is not always the case: the op
Tom Lane wrote:
> Jeff Davis writes:
> > Currently, the check for exclusion constraints performs a sanity check
> > that's slightly too strict -- it assumes that a tuple will conflict with
> > itself. That is not always the case: the operator might be "<>", in
> > which case it's perfectly valid f
Jeff Davis writes:
> Currently, the check for exclusion constraints performs a sanity check
> that's slightly too strict -- it assumes that a tuple will conflict with
> itself. That is not always the case: the operator might be "<>", in
> which case it's perfectly valid for the search for conflict
Currently, the check for exclusion constraints performs a sanity check
that's slightly too strict -- it assumes that a tuple will conflict with
itself. That is not always the case: the operator might be "<>", in
which case it's perfectly valid for the search for conflicts to not find
itself.
This
14 matches
Mail list logo
