Re: NOT DEFERRABLE as default, why and how to manage it.

Поиск
Список
Период
Сортировка
От Ivan Sergio Borgonovo
Тема Re: NOT DEFERRABLE as default, why and how to manage it.
Дата
Msg-id 20080819122818.4fbd79fe@dawn.webthatworks.it
обсуждение исходный текст
Ответ на Re: NOT DEFERRABLE as default, why and how to manage it.  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Ответы Re: NOT DEFERRABLE as default, why and how to manage it.  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-general
On Tue, 19 Aug 2008 10:49:11 +0200
Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:

> On Tue, 19 Aug 2008 11:20:08 +0300
> Peter Eisentraut <peter_e@gmx.net> wrote:

> > Am Tuesday, 19. August 2008 schrieb Ivan Sergio Borgonovo:
> > > I just learnt that NOT DEFERRABLE is default.

> > > Is it mandated by SQL standard?

> > Yes.

> Is there any reason they put it that way in the standard other than
> the mantra "stricter is better"?

After reflecting a bit I think it is a matter of "failing earlier".
But it doesn't make things more transparent.
Since there is no simple standard way to see which constraints are
deferrable and no simple way to alter them.

If you expect a constraint to be deferrable and it is not there are
higher chances you'll have some warning.
If you expect a constraint to be not deferrable but it is...
the chances that something you're not expecting will silently happen
are higher.
But you can still get surprises in both cases.

It would be nice to know some way which constraint are checked
during a transaction so it would be easier to see wich ones you
really need to defer and which one were declared as not deferrable.

anyway are there guidelines on how/when changing directly the system
tables?

--
Ivan Sergio Borgonovo
http://www.webthatworks.it


В списке pgsql-general по дате отправления:

Предыдущее
От: "Albe Laurenz"
Дата:
Сообщение: Re: How to execute 'set session role' from plpgsql function?
Следующее
От: "c k"
Дата:
Сообщение: CASE