Re: Expression indexes and dependecies
| От | Pavan Deolasee |
|---|---|
| Тема | Re: Expression indexes and dependecies |
| Дата | |
| Msg-id | CABOikdOkRUir+1=62Uhd9i9oS9S5Ju+tPg4cJOk32PrVkZ8cvw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Expression indexes and dependecies (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Expression indexes and dependecies
|
| Список | pgsql-hackers |
On Thu, Jul 25, 2013 at 6:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This constraint would most likely fail if someone was to restore the table from a dump.
Well, it's probably somewhat historical, but I doubt we'd want to
tighten it up now. Here's an example of a sensible CHECK that's
only stable:
create ... last_update timestamptz check (last_update <= now()) ...
Agree. That looks like a very sensible use case and something not possible without support for mutable functions.
More generally, I think the argument was that the behavior of a
non-immutable CHECK would at least be easy to understand, assuming you
know that the check will only be applied at row insertion or update.
But they are also prone to unexpected behaviour, no ? For example, a slight variation of the above example is:
create ... last_update timestamptz check (last_update <= now() and last_update >= now() - '1 week'::interval) ...
Given that we haven't seen any complaints may mean I am imagining a problem that does not exist in practice, though I thought the example looks quite sensible too.
Thanks,
В списке pgsql-hackers по дате отправления: