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