Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1iSpJ0-000109-Db
	for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2019 21:27:02 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1iSpIy-0005Am-H1
	for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2019 21:27:00 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <bruce@momjian.us>)
	id 1iSpIy-0005Ac-84; Thu, 07 Nov 2019 21:27:00 +0000
Received: from momjian.us ([72.94.173.45])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <bruce@momjian.us>)
	id 1iSpIv-0004VQ-Aa; Thu, 07 Nov 2019 21:26:59 +0000
Received: from bruce by momjian.us with local (Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1iSpIt-0008Sl-5y; Thu, 07 Nov 2019 16:26:55 -0500
Date: Thu, 7 Nov 2019 16:26:55 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Eugen Konkov <kes-kes@yandex.ru>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
	pgsql-docs@lists.postgresql.org
Subject: Re: Does 'instead of delete' trigger support modification of OLD
Message-ID: <20191107212655.GA487@momjian.us>
References: <919823407.20191029175436@yandex.ru>
 <20191106185935.GE1843@momjian.us>
 <1771593631.20191107112032@yandex.ru>
 <352093181.20191107112429@yandex.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <352093181.20191107112429@yandex.ru>
User-Agent: Mutt/1.10.1 (2018-07-13)
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

On Thu, Nov  7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
> Hello Eugen,
> 
> Thursday, November 7, 2019, 11:20:32 AM, you wrote:
> 
> >> I looked in the CREATE TRIGGER manual page and found this:
> 
> >>         https://www.postgresql.org/docs/12/sql-createtrigger.html
> >>         If the trigger fires before or instead of the event, the trigger
> >>         can skip the operation for the current row, or change the row
> >>         being inserted (for INSERT and UPDATE operations only).
> 
> >> I don't see the "(for INSERT and UPDATE operations only)" language in
> >> the main trigger documentation,
> >> https://www.postgresql.org/docs/current/trigger-definition.html.  I have
> >> written the attached patch to fix that.  Does that help?
> 
> > No.   If   we document that PG does not allow to modify OLD at instead
> > of  trigger,  the  we can not implement that. Probably we can put note
> > that  "currently  modification of the trigger row for RETURNING is not
> > implemented"
> 
> sorry, typo. Please read:
> "currently  modification of the trigger row for DELETE RETURNING is notimplemented"

In looking at the existing docs, the bullet above the quoted text says:

	For row-level INSERT and UPDATE triggers only, the returned row becomes
	                                         ----
	the row that will be inserted or will replace the row being updated.
	This allows the trigger function to modify the row being inserted or
	updated.

First, notice "only", which was missing from the later sentence:

	For <command>INSERT</command> and <command>UPDATE</command>
	operations [only], the trigger may modify the
	<varname>NEW</varname> row before returning it.

which I have now added with my applied patch to all supported releases. 

The major use of modifying NEW is to modify the data that goes into the
database, and its use to modify data seen by later executed triggers, or
by RETURNING, is only a side-effect of its primary purpose.  Therefore,
it is not surprising that, since DELETE does not modify any data, just
removes it, that the modification of OLD to appear in later triggers or
RETURNING is not supported.

> >> As far as allowing DELETE to modify the trigger row for RETURNING, I am
> >> not sure how much work it would take to allow that, but it seems like it
> >> is a valid requite, and if so, I can add it to the TODO list.
> 
> > Yes,  Add please into TODO the feature to "allowing DELETE to modify the trigger row
> > for  RETURNING".  Becuase, as I have described at first letter, without
> > this the RETURNING rows **does not correspond actually deleted data**
> 
> > Thank you.

I have added a TODO item:

	Allow DELETE triggers to modify rows, for use by RETURNING 

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +