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

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: NOT DEFERRABLE as default, why and how to manage it.
Date: 2008-08-19 10:28:18
Message-ID: 20080819122818.4fbd79fe@dawn.webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 19 Aug 2008 10:49:11 +0200
Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> wrote:

> On Tue, 19 Aug 2008 11:20:08 +0300
> Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message c k 2008-08-19 10:55:52 CASE
Previous Message Albe Laurenz 2008-08-19 09:49:28 Re: How to execute 'set session role' from plpgsql function?