Re: Optimising Foreign Key checks

On Sat, Jun 8, 2013 at 5:41 PM, Noah Misch <noah@leadboat.com> wrote:
> This does appear to specify FK timing semantics like PostgreSQL gives today.
> Namely, it does not permit a FK-induced error when later actions of the query
> that prompted the check could possibly remedy the violation.

Yeah.  Standard or no standard, I think we'd have unhappy users if we
broke that.

>> I can't see anything there that stops me applying locks as we go, but

Not sure I follow that bit but...

> Likewise; I don't see why we couldn't perform an optimistic check ASAP and
> schedule a final after-statement check when an early check fails.  That
> changes performance characteristics without changing semantics.

...this seems like it might have some promise; but what if the action
we're performing isn't idempotent?  And how do we know?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company