Re: NOT DEFERRABLE as default, why and how to manage it. - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject Re: NOT DEFERRABLE as default, why and how to manage it.
Date
Msg-id 20080819122818.4fbd79fe@dawn.webthatworks.it
Whole thread Raw
In response to Re: NOT DEFERRABLE as default, why and how to manage it.  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Responses Re: NOT DEFERRABLE as default, why and how to manage it.  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: How to execute 'set session role' from plpgsql function?
Next
From: "c k"
Date:
Subject: CASE