Comments on: Database for a Zoo: the problem and the solution http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/ Ideas on Databases, Logic, and Language by Jeff Davis Tue, 19 Jun 2012 16:18:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2374 Jeff Davis Tue, 27 Sep 2011 16:50:13 +0000 http://thoughts.davisjeff.com/?p=315#comment-2374 Interesting. Did that allow constraints that would work even with concurrent updates? Interesting. Did that allow constraints that would work even with concurrent updates?

]]> By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2373 Jeff Davis Tue, 27 Sep 2011 16:49:27 +0000 http://thoughts.davisjeff.com/?p=315#comment-2373 I'm glad you found it useful! To prevent "gaps" is a little tricky, but perhaps it can be done with triggers, row-level locks, and exclusion constraints. In a way, it's kind of like a foreign key into the same table. The tricky part is the initial condition for a group where there is no other period to "connect" with. I'll think about it a little more and write up a blog post about it. I’m glad you found it useful!

To prevent “gaps” is a little tricky, but perhaps it can be done with triggers, row-level locks, and exclusion constraints. In a way, it’s kind of like a foreign key into the same table. The tricky part is the initial condition for a group where there is no other period to “connect” with.

I’ll think about it a little more and write up a blog post about it.

]]> By: Bay Area Guy http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2363 Bay Area Guy Sun, 25 Sep 2011 20:24:38 +0000 http://thoughts.davisjeff.com/?p=315#comment-2363 Reminds me of REFUSE rules in the original postgres (not postgresql) rule system. Reminds me of REFUSE rules in the original postgres (not postgresql) rule system.

]]> By: Gary Clarke http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2358 Gary Clarke Sun, 25 Sep 2011 11:07:47 +0000 http://thoughts.davisjeff.com/?p=315#comment-2358 Hi Jeff I believe that your Exlusion Contraints are the Most Innovative new capability in any rdbms over the few years and in Postgres since Window Functions in v 8.4 - Particularly in conjunction with your Period Datatype (such a shame range types did not make 9.1). We could not find a way to Exclude Period Gaps in v 9 - Does enabling opertor in 9.1 now make this possible ? Hi Jeff I believe that your Exlusion Contraints are the Most Innovative new capability in any rdbms over the few years and in Postgres since Window Functions in v 8.4 – Particularly in conjunction with your Period Datatype (such a shame range types did not make 9.1). We could not find a way to Exclude Period Gaps in v 9 – Does enabling opertor in 9.1 now make this possible ?

]]> By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2353 Jeff Davis Thu, 22 Sep 2011 15:38:17 +0000 http://thoughts.davisjeff.com/?p=315#comment-2353 btree_gist has been around for a while, but you're right that the 9.0 version wasn't enough: the 9.1 version is the first to searching on "<>", so the 9.0 version would not have worked for this example. That's also the reason that I couldn't use btree directly (it still doens't allow searches on <>). It's also true that you can't mix and match index types. And, as I mention below, there's the overly-conservative error check in 9.0 that was removed in 9.1. btree_gist has been around for a while, but you’re right that the 9.0 version wasn’t enough: the 9.1 version is the first to searching on “<>“, so the 9.0 version would not have worked for this example. That’s also the reason that I couldn’t use btree directly (it still doens’t allow searches on <>).

It’s also true that you can’t mix and match index types.

And, as I mention below, there’s the overly-conservative error check in 9.0 that was removed in 9.1.

]]> By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2352 Jeff Davis Thu, 22 Sep 2011 15:33:54 +0000 http://thoughts.davisjeff.com/?p=315#comment-2352 There was an extra error check that we left in 9.0 that was (intentionally) more conservative than required, with the idea that it might give more information if someone ran into a bug. The extra check threw an error if the enforcement mechanism, while looking for conflicting tuples, didn't even find the tuple being currently inserted. The underlying assumption there is that, if there is an exclusion constraint, then a tuple will always conflict with itself. However, that's not true for cases such as this "zoo" example, or for empty ranges in a schedule conflict example. We considered trying to document that somehow, but since the limitation was removed in 9.1, the cost of carrying around such a caveat seemed to outweigh the benefits. There was an extra error check that we left in 9.0 that was (intentionally) more conservative than required, with the idea that it might give more information if someone ran into a bug.

The extra check threw an error if the enforcement mechanism, while looking for conflicting tuples, didn’t even find the tuple being currently inserted. The underlying assumption there is that, if there is an exclusion constraint, then a tuple will always conflict with itself. However, that’s not true for cases such as this “zoo” example, or for empty ranges in a schedule conflict example.

We considered trying to document that somehow, but since the limitation was removed in 9.1, the cost of carrying around such a caveat seemed to outweigh the benefits.

]]> By: Richard Broersma Jr http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2351 Richard Broersma Jr Thu, 22 Sep 2011 14:20:35 +0000 http://thoughts.davisjeff.com/?p=315#comment-2351 My understanding is that exclusion constraints rely upon the features on a single index type. In 9.0 there wasn't a contrib module for the new index type btree_gist, so you were either limited to the operations of simple btree indexes or gist indexes. And there wasn't a way for building multi-column constraints that used different types of indexes. My understanding is that exclusion constraints rely upon the features on a single index type. In 9.0 there wasn’t a contrib module for the new index type btree_gist, so you were either limited to the operations of simple btree indexes or gist indexes. And there wasn’t a way for building multi-column constraints that used different types of indexes.

]]> By: eggyknap http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2350 eggyknap Thu, 22 Sep 2011 03:35:03 +0000 http://thoughts.davisjeff.com/?p=315#comment-2350 So what changed between 9.0 and 9.1, w.r.t. exclusion constraints? The particular bit of documentation linked above looks the same (not that it should be expected to have changed; it's just that it was the one place I immediately thought to look). So what changed between 9.0 and 9.1, w.r.t. exclusion constraints? The particular bit of documentation linked above looks the same (not that it should be expected to have changed; it’s just that it was the one place I immediately thought to look).

]]> By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2349 Jeff Davis Wed, 21 Sep 2011 17:42:02 +0000 http://thoughts.davisjeff.com/?p=315#comment-2349 "Perhaps in the future once exclusion constraints are fully implements" I hope they are, two releases of them now. I am working on some other things around exclusion constraints, like Range Types, but Exclusion Constraints themselves should be reliable. "it be nice if a mechanism could be implemented that could translate ASSERTION constraints or TABLE sub-Select constraints into exclusion constraints" Although exclusion constraints are more general than unique, they are still explicitly a special case (more special than Assert or CHECK with subselects). Exclusion constraints are, essentially, the special case of constraints that can be enforced by searching for conflicting tuples (which can be implemented with efficient searches, like an index search). The most general constraints need something more like serializable snapshot isolation, because the test might be for some very complex violation that wouldn't be found just by looking for a certain class of tuples that conflict. “Perhaps in the future once exclusion constraints are fully implements”

I hope they are, two releases of them now. I am working on some other things around exclusion constraints, like Range Types, but Exclusion Constraints themselves should be reliable.

“it be nice if a mechanism could be implemented that could translate ASSERTION constraints or TABLE sub-Select constraints into exclusion constraints”

Although exclusion constraints are more general than unique, they are still explicitly a special case (more special than Assert or CHECK with subselects). Exclusion constraints are, essentially, the special case of constraints that can be enforced by searching for conflicting tuples (which can be implemented with efficient searches, like an index search).

The most general constraints need something more like serializable snapshot isolation, because the test might be for some very complex violation that wouldn’t be found just by looking for a certain class of tuples that conflict.

]]> By: Jeff Davis http://thoughts.davisjeff.com/2011/09/21/database-for-a-zoo-the-problem-and-the-solution/comment-page-1/#comment-2348 Jeff Davis Wed, 21 Sep 2011 17:32:02 +0000 http://thoughts.davisjeff.com/?p=315#comment-2348 Yes, true. A little bit more difficult to specify, and probably more difficult to make it efficient though. Yes, true.

A little bit more difficult to specify, and probably more difficult to make it efficient though.

]]>