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
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

In response to

Responses

Browse pgsql-hackers by date

  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