X-Original-To: pgsql-interfaces-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id CE84C9FA31F for ; Thu, 29 Jun 2006 14:47:44 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 27602-03 for ; Thu, 29 Jun 2006 14:47:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.zanthus.com.br (mail.zanthus.com.br [200.212.65.85]) by postgresql.org (Postfix) with ESMTP id 61EC89FA081 for ; Thu, 29 Jun 2006 14:47:37 -0300 (ADT) Received: from cprsakai ([192.168.0.71]) by mail.zanthus.com.br (8.13.4/8.13.4/Debian-3) with ESMTP id k5THpGh8014167; Thu, 29 Jun 2006 14:51:16 -0300 Reply-To: From: "Rodrigo Sakai" To: "'Tom Lane'" Cc: Subject: RES: RES: Creating a new type Date: Thu, 29 Jun 2006 14:47:48 -0300 Message-ID: <002701c69ba4$232d48f0$4700a8c0@TREEZANTHUS> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C69B8A.FDE010F0" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20097.1151588820@sss.pgh.pa.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcabgxdE0YpQkzGcRBiHpPp8f9ReMQAG7cQw X-Zanthus-MailScanner: Found to be clean X-Zanthus-MailScanner-From: rodrigo.sakai@zanthus.com.br X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/47 X-Sequence-Number: 6188 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C69B8A.FDE010F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >> So, I have to guarantee that this situation doesn't occur! But I don't >> want to use triggers because this check must be done on almost all tables >> that uses the type: >The fact that you don't want to do it doesn't make it the wrong >solution ;-) In fact it makes the wrong solution! Having to define a trigger on the table for this field (emp_time) to guarantee this kind of integrity is the same thing to have to define a trigger on an integer field to guarantee that all data inserted is an integer value! Again! Explaining better! I'm dealing with Temporal Databases (researched by Richard Snodgrass). One of the issues is to maintain the integrity constraints through temporal data. So, it is necessary that a field doesn't have two different values in the same interval of time, like I demonstrated in the example! I agree that with triggers this situation is resolved fast and easy! But what I want is this feature became transparent for the user! So far, you have helped a lot, but do you have other idea? >At the moment there is no other way than a trigger. There's been some >speculation about whether GIST indexes could be extended to enforce >conditions like "no overlapping values in this column" (as a >generalization of the concept of unique indexes). No one's tried to >make that happen, though. >BTW, you might want to look at the "timetravel" code in contrib/spi/ >... it's a tad old and crufty, but it sounds like you are trying to do >something pretty similar to that. I didn't have time to see timetravel yet! Thanks again! ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend ------=_NextPart_000_0028_01C69B8A.FDE010F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

>> So, I have to guarantee = that this situation doesn't occur! But I don't

>> want to use triggers because this = check must be done on almost all tables

>> that uses the = type:

>The fact that you don't want to do it = doesn't make it the wrong

>solution ;-)

In fact it makes the = wrong solution! Having to define a trigger on the table for this field = (emp_time) to guarantee this kind of integrity is the same thing to have to define a trigger on = an integer field to guarantee that all data inserted is an integer = value!

Again! Explaining = better! I'm dealing with Temporal Databases (researched by Richard Snodgrass). One = of the issues is to maintain the integrity constraints through temporal data. = So, it is necessary that a field doesn't have two different values in the same interval of time, like I demonstrated in the example! I agree that with = triggers this situation is resolved fast and easy! But what I want is this = feature became transparent for the user!

So far, you have = helped a lot, but do you have other idea?

>At the moment there is no other way than = a trigger. There's been some

>speculation about whether GIST indexes = could be extended to enforce

>conditions like "no overlapping = values in this column" (as a

>generalization of the concept of unique indexes). No one's tried to

>make that happen, = though.

>BTW, you might want to look at the "timetravel" code in contrib/spi/

>... it's a tad old and crufty, but it sounds like you are = trying to do

>something pretty similar to = that.

I didn’t have = time to see timetravel yet!

Thanks = again!

---------------------------(end of broadcast)---------------------------

TIP 6: explain analyze is your = friend

------=_NextPart_000_0028_01C69B8A.FDE010F0--