Re: [GENERAL] deferrable foreign keys
Hallo Tom, > Morus Walter writes: > > are there downsides of making foreign keys deferrable (but initially > > immediate) for updates, when the transaction does not set the > > constraint behaviour to deferred? > > > I'd expect that to have the same behaviour as non deferrable foreign > > keys. > > What I don't understand is, why is non deferrable the default, then. > > Because the SQL standard says so. Ok. Understood. > I don't believe there is any actual > penalty for deferrable within the PG implementation, but perhaps there > is in other systems' implementations. > Thanks a lot for your help. Morus -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] deferrable foreign keys
Morus Walter writes: > are there downsides of making foreign keys deferrable (but initially > immediate) for updates, when the transaction does not set the > constraint behaviour to deferred? > I'd expect that to have the same behaviour as non deferrable foreign > keys. > What I don't understand is, why is non deferrable the default, then. Because the SQL standard says so. I don't believe there is any actual penalty for deferrable within the PG implementation, but perhaps there is in other systems' implementations. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] deferrable foreign keys
On Wed, Dec 2, 2009 at 2:29 PM, Morus Walter wrote: > Hi, > > are there downsides of making foreign keys deferrable (but initially > immediate) for updates, when the transaction does not set the > constraint behaviour to deferred? > > I'd expect that to have the same behaviour as non deferrable foreign > keys. > What I don't understand is, why is non deferrable the default, then. > > it is just sometimes desired to not check the constraints, until comit. For instance, if you run bit of code that is old, and you don't want to mess around with keys. Or you have some strange way of putting information together. Basically it is all about order of operation within transaction. Sometimes it cannot be guaranteed, and hence an option to defer the constraint check. -- GJ
[GENERAL] deferrable foreign keys
Hi, are there downsides of making foreign keys deferrable (but initially immediate) for updates, when the transaction does not set the constraint behaviour to deferred? I'd expect that to have the same behaviour as non deferrable foreign keys. What I don't understand is, why is non deferrable the default, then. So maybe I miss something. regards Morus -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
