Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TxxZ4-0005sA-Tc for pgsql-sql@arkaria.postgresql.org; Wed, 23 Jan 2013 10:28:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TxxZ4-0003GO-1I for pgsql-sql@arkaria.postgresql.org; Wed, 23 Jan 2013 10:28:18 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TxxZ3-0003GC-7d for pgsql-sql@postgresql.org; Wed, 23 Jan 2013 10:28:17 +0000 Received: from mail-lb0-f181.google.com ([209.85.217.181]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TxxZ1-0006zy-Ev for pgsql-sql@postgresql.org; Wed, 23 Jan 2013 10:28:16 +0000 Received: by mail-lb0-f181.google.com with SMTP id gm6so2089041lbb.12 for ; Wed, 23 Jan 2013 02:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=hAF0xdfr1MvlFSfnuIsuNIrYdZ4tBwgqL8KY2XZuy04=; b=SSsX31CzYqmp2b4n2QLg39QF6TjAO7dXuUbSh6XKo5DLe6q/7o1IuX0Q358OwlXyWg nUwEH/JlR6n8FmEfuVzju5ww4ISJDndHR11m8e7MiAROWw2lp8R6HjGM1QcnGy7waZm5 vLTFVMn7GZzT1nwPibaAVGORBYqRmzTLNz4z5Eh287yOnrhItRBpiOb1Fb98evUnvqfV 04iBNWNJI5QKnoHATu6d70zxitRdYNpw2+U/RAi4tWCE2vMzJmzxDC4U957lEhQGGD9j i3CbinRYzHDs4fVaLHknQUHaQcbhIqhVzXubKcbGHa/2WEBcxYfPhIksHgNRXvM6dp2y DuhA== X-Received: by 10.112.102.9 with SMTP id fk9mr498283lbb.100.1358936894066; Wed, 23 Jan 2013 02:28:14 -0800 (PST) Received: from hek506.localnet ([2001:7c0:409:274:687e:f7f9:9161:67d6]) by mx.google.com with ESMTPS id ie3sm8057400lab.4.2013.01.23.02.28.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 02:28:12 -0800 (PST) From: Matthias Nagel To: pgsql-sql@postgresql.org Subject: Range types (DATERANGE, TSTZRANGE) in a foreign key with "inclusion" logic Date: Wed, 23 Jan 2013 11:28:10 +0100 Message-ID: <1678334.8llTyI05Te@hek506> User-Agent: KMail/4.9.3 (Linux/3.6.11-gentoo; KDE/4.9.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org Hello everybody, first a big thank you to all that make the range types possible. They are great, especially if one runs a database to manage a student's university dormitory with a lot of temporal information like rental agreements, room allocations, etc. At the moment we are redesigning our database scheme for PosgreSQL 9.2, because the new range types and especially the "EXCLUSION" constraints allow to put a lot more (business) logic into the database scheme than before. But there is one feature missing (or I am too stupid to find it). Let's say we have some kind of container with a lifetime attribute, i.e. something like that CREATE TABLE container ( id SERIAL PRIMARY KEY, lifetime DATERANGE ); Further, there are items that must be part of the container and these items have a lifetime, too. CREATE TABLE item ( id SERIAL PRIMARY KEY, container_id INTEGER, lifetime DATERANGE, FOREIGN KEY (container_id) REFERENCES container ( id ), EXCLUDE USING gist ( container_id WITH =, lifetime WITH && ) ); The foreign key ensures that items are only put into containers that really exist and the exclude constraint ensure that only one item is member of the same container at any point of time. But actually I need a little bit more logic. The additional contraint is that items must only be put into those containers whose lifetime covers the lifetime of the item. If an item has a lifetime that exceeds the lifetime of the container, the item cannot be put into that container. If an item is already in a container (with valid lifetimes) and later the container or the item is updated such that either lifetime is modified and the contraint is not fullfilled any more, this update must fail. I would like to do someting like: FOREIGN KEY ( container_id, lifetime ) REFERENCES other_table ( id, lifetime ) USING gist ( container_id WITH =, lifetime WITH <@ ) (Of course, this is PosgreSQL-pseudo-code, but it hopefully make clear what I want.) So, now my questions: 1) Does this kind of feature already exist in 9.2? If yes, a link to the documentation would be helpful. 2) If this feature does not directly exist, has anybody a good idea how to mimic the intended behaviour? 3) If neither 1) or 2) applies, are there any plans to integrate such a feature? I found this discussion http://www.postgresql.org/message-id/4F8BB9B0.5090708@darrenduncan.net . Does anybody know about the progress? Having range types and exclusion contraints are nice, as I said in the introdruction. But if the reverse (foreign key with inclusion) would also work, the range type feature would really be amazing. Best regards, Matthias Nagel ---------------------------------------------------------------------- Matthias Nagel Willy-Andreas-Allee 1, Zimmer 506 76131 Karlsruhe Telefon: +49-721-8695-1506 Mobil: +49-151-15998774 e-Mail: matthias.h.nagel@gmail.com ICQ: 499797758 Skype: nagmat84 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql