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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2006-02-06 01:09:16 | Re: Shared memory and memory context question |
Previous Message | Stephan Szabo | 2006-02-05 22:08:12 | Re: Copy From & Insert UNLESS |