small exclusion constraints patch
in [PgSql]
|
Prev: unnailing shared relations (was Re: global temporary tables)
Next: [HACKERS] (9.1) btree_gist support for searching on "not equals"
From: Robert Haas on 29 May 2010 22:56 On Sat, May 29, 2010 at 6:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)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 think that anyone's very likely to write a <>-like index > operator. It's approximately useless to use an index for such a query. > > 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 to read http://archives.postgresql.org/pgsql-hackers/2010-05/msg01175.php I'll make it two dollars. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 May 2010 23:40 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sat, May 29, 2010 at 6:11 PM, Tom Lane <tgl(a)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 not. > In fact, if you promise not to read > http://archives.postgresql.org/pgsql-hackers/2010-05/msg01175.php I'll > make it two dollars. 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 actually asked for the ability to do that? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 May 2010 23:55 On Sat, May 29, 2010 at 11:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sat, May 29, 2010 at 6:11 PM, Tom Lane <tgl(a)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 not. >> In fact, if you promise not to read >> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01175.php I'll >> make it two dollars. > > 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 actually asked > for the ability to do that? 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 to whether Jeff's use case is a cute hack or something that people will really want to do, I think the jury's still out on that one. But I don't think we should make it not work unless we have a concrete reason, and I haven't heard one yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 30 May 2010 06:54 On 2010-05-30 06:55 +0300, Robert Haas wrote: > On Sat, May 29, 2010 at 11:40 PM, Tom Lane <tgl(a)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 where anyone actually asked >> for the ability to do that? > > 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 , you can already do that. Having said that, I also think that supporting <> in exclusion constraints would be useful. I can't come up with a real-world use case right now though. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 30 May 2010 12:56
On Sun, May 30, 2010 at 10:01 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Marko Tiikkaja <marko.tiikkaja(a)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 >> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01177.php , you >> can already do that. > > Yes. This is NOT about constraining a table to hold only one row. > It's about requiring all its rows to hold the same value (in some > column(s)), without predetermining exactly which value that will be. > I think the use-case for that is really extremely narrow. It probably is pretty narrow. After all, exclusion constraints in general are something that not everyone needs, and the ordinary use case of preventing two intervals or regions from overlapping will doubtless be far more common than this one. Still, I'm not sure how that's relevant. The fact that not very many people will want to do something is not a reason to prevent it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |