Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZP85i-0008Q1-Ff for pgsql-docs@arkaria.postgresql.org; Tue, 11 Aug 2015 11:51:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZP85h-0006uR-DG for pgsql-docs@arkaria.postgresql.org; Tue, 11 Aug 2015 11:51:37 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZP85g-0006uI-Ov for pgsql-docs@postgresql.org; Tue, 11 Aug 2015 11:51:36 +0000 Received: from mail-ig0-x22f.google.com ([2607:f8b0:4001:c05::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZP85Z-0007tF-V6 for pgsql-docs@postgresql.org; Tue, 11 Aug 2015 11:51:35 +0000 Received: by igbij6 with SMTP id ij6so88687934igb.1 for ; Tue, 11 Aug 2015 04:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rk2MiW5I5fW6SdYXXa21+01YiYAqGDrf+JQ38HMQ2DY=; b=hJw4JHb+7R0juJPCfL2b97/YiZbMrLdgxMgn4e0NguWloqLgL8vYeWpoAabsUIN1l0 erl1UuxM2T0ftad8MyB7zUXA+Nni68owskBmc7WR4J0qW5fkqpGQW4VWgwBx3NxrNecf 22gcs0YbXvbyzNVQfXt0iqSOdklmYsanD4qX0I9FYx/lHc3/nDjT5c5NMos46Y2xRGq1 GKrR8Gnq14+OhcGyUYnJrgu3W27uik+NJUJ4eZwQ5szvn9AFbpnqlrIw9I3DOFkMEJ4n pK8XHPlxfXui7VQmxgIRKX88HiUbjVsQhgf06e9zwdtv1snuQGkdSweSnq9cE4B6A3VH bgdw== MIME-Version: 1.0 X-Received: by 10.50.73.170 with SMTP id m10mr17886829igv.60.1439293888849; Tue, 11 Aug 2015 04:51:28 -0700 (PDT) Received: by 10.79.111.196 with HTTP; Tue, 11 Aug 2015 04:51:28 -0700 (PDT) In-Reply-To: <55C9DD49.8060706@joh.to> References: <55C9DD49.8060706@joh.to> Date: Tue, 11 Aug 2015 14:51:28 +0300 Message-ID: Subject: Re: 36.3 Writing Tigger Functions in C From: Dmitry Igrishin To: Marko Tiikkaja Cc: pgsql-docs Content-Type: multipart/alternative; boundary=089e01183996f8fb6f051d07b8c0 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --089e01183996f8fb6f051d07b8c0 Content-Type: text/plain; charset=UTF-8 2015-08-11 14:32 GMT+03:00 Marko Tiikkaja : > On 8/11/15 12:47 PM, Dmitry Igrishin wrote: > >> tg_trigtuple: >> I'm not sure why "skip the operation" is here: >> "if you don't want to replace the row with a different one (in the >> case of INSERT) or skip the operation" >> > > Returning NULL from a row-level BEFORE trigger skips the operation which > fired the trigger. So for an INSERT, any triggers which would otherwise > fire after the current trigger are not fired, and the row is not INSERTed > into the table. Yes, but it's absolutely unclear in this place of the documentation. Thus, "If this trigger was fired for an INSERT or DELETE then this is what you should return from the function if you don't want to replace the row with a different one (in the case of INSERT) or skip the operation." should be replaced with something like "If this trigger was fired for an INSERT or DELETE then this is what you should return from the function if you don't want to replace the row with a different one (in the case of INSERT). (To skip the operation you should return NULL.)" ? -- // Dmitry. --089e01183996f8fb6f051d07b8c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-08-11 14:32 GMT+03:00 Marko Tiikkaja <marko@joh.to>:
=
On 8/11/15 12:47 PM, Dmitry= Igrishin wrote:
tg_trigtuple:
I'm not sure why "skip the operation" is here:
"if you don't want to replace the row with a different one (in the=
case of INSERT) or skip the operation"

Returning NULL from a row-level BEFORE trigger skips the operation which fi= red the trigger.=C2=A0 So for an INSERT, any triggers which would otherwise= fire after the current trigger are not fired, and the row is not INSERTed = into the table.
Yes, but it's absolutely unclear in th= is place of the documentation.
Thus,
"If this trig= ger was fired for an INSERT or DELETE then this is what you
shoul= d return from the function if you don't want to replace the row with a<= /div>
different one (in the case of INSERT) or skip the operation."= ;
should be replaced with something like
"If this = trigger was fired for an INSERT or DELETE then this is what you
s= hould return from the function if you don't want to replace the row wit= h a
different one (in the case of INSERT). (To skip the operation= you should
return NULL.)" ?

--
// Dmitry.

--089e01183996f8fb6f051d07b8c0--