RES: RES: Creating a new type
| От | Rodrigo Sakai |
|---|---|
| Тема | RES: RES: Creating a new type |
| Дата | |
| Msg-id | 002701c69ba4$232d48f0$4700a8c0@TREEZANTHUS обсуждение исходный текст |
| Ответ на | Re: RES: Creating a new type (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-interfaces |
>> 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
В списке pgsql-interfaces по дате отправления: