Skip site navigation (1) Skip section navigation (2)

Re: Copy From & Insert UNLESS

From: James William Pye <pgsql(at)jwp(dot)name>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Copy From & Insert UNLESS
Date: 2006-02-06 00:51:01
Message-ID: 20060206005101.GA97445@lit.jwp.name (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
> Have you considered how this might work with spec-compliant constraint
> timing?

I haven't gone so far as to look into the spec, yet. [Noise of rustling papers]

However, constraints referenced in an UNLESS clause that are deferred, in any
fashion, should probably be "immediated" within the context of the command.
Perhaps a WARNING or NOTICE would be appropriately informative if UNLESS were
to actually alter the timing of a given constraint.

> I think even in inserting cases, a later trigger before statement
> end could in some cases un-violate a constraint, so checking before insert
> won't actually be the same behavior as the normal constraint handling
> which seems bad for this kind of system.

Any facility that can alter the tuple before it being inserted into the heap
should probably be exercised prior to the application of the tuple against 
UNLESS's behavior. The implementation of UNLESS will probably completely change
ExecConstraints(), which comes after the firing of BEFORE triggers and before
heap_insert(). Beyond that, I am not sure what other considerations should be
made with respect to triggers. So, UNLESS should/will be applied after BEFORE
triggers, but before "non-UNLESS specified" constraints. ;)
-- 
Regards, James William Pye

In response to

Responses

pgsql-hackers by date

Next:From: Neil ConwayDate: 2006-02-06 01:09:16
Subject: Re: Shared memory and memory context question
Previous:From: Stephan SzaboDate: 2006-02-05 22:08:12
Subject: Re: Copy From & Insert UNLESS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group