Jeff Davis pg...@j-davis.com 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
On 2010-05-30 06:55 +0300, Robert Haas wrote:
On Sat, May 29, 2010 at 11:40 PM, Tom Lane t...@sss.pgh.pa.us 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On Sun, May 30, 2010 at 10:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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.
Robert Haas robertmh...@gmail.com 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
On Fri, May 28, 2010 at 10:32 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Jeff Davis pg...@j-davis.com 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
Robert Haas robertmh...@gmail.com 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
On Sat, May 29, 2010 at 06:11:57PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Sat, May 29, 2010 at 6:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, May 29, 2010 at 6:11 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, May 29, 2010 at 11:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 29, 2010 at 6:11 PM, Tom Lane t...@sss.pgh.pa.us 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?
Tom Lane wrote:
Jeff Davis pg...@j-davis.com 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
Jeff Davis pg...@j-davis.com 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
13 matches
Mail list logo