Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <bruce@momjian.us>) id 1T1UBb-0002tv-6O
	for pgsql-docs@postgresql.org; Wed, 15 Aug 2012 03:22:23 +0000
Received: from momjian.us ([72.94.173.45])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <bruce@momjian.us>) id 1T1UBZ-0004NR-H4
	for pgsql-docs@postgresql.org; Wed, 15 Aug 2012 03:22:22 +0000
Received: from bruce by momjian.us with local (Exim 4.72)
	(envelope-from <bruce@momjian.us>)
	id 1T1UBY-0007pz-7n; Tue, 14 Aug 2012 23:22:20 -0400
Date: Tue, 14 Aug 2012 23:22:20 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Josh Kupershmidt <schmiddy@gmail.com>,
	pgsql-docs <pgsql-docs@postgresql.org>
Subject: Re: lo_manage trigger on updates
Message-ID: <20120815032220.GC25473@momjian.us>
References: 
 <CAK3UJRHaEuzfnZaxarcV8=RP1sC5xLxumzqx6iiyqpJVS89rjw@mail.gmail.com>
	<CA+TgmoZQEbFFRR9X25azdBMpWcYx6RDncTODF0hOcR9GYRz0dw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+TgmoZQEbFFRR9X25azdBMpWcYx6RDncTODF0hOcR9GYRz0dw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201208/18
X-Sequence-Number: 7411


--ibTvN161/egqYuK8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Mon, Oct 10, 2011 at 01:18:56PM -0400, Robert Haas wrote:
> On Thu, Aug 11, 2011 at 11:43 PM, Josh Kupershmidt <schmiddy@gmail.com> wrote:
> > I think the doc section about using lo_manage() as a trigger:
> >   http://www.postgresql.org/docs/current/static/lo.html
> >
> > could have its example tweaked to use a column-level BEFORE UPDATE
> > trigger, so as to save unnecessary trigger firings. Something like the
> > attached, perhaps?
> 
> Uh, wow.  That syntax is horribly surprising, isn't it?  My eyes want
> to parse it as:
> 
> BEFORE (UPDATE OF raster) OR (DELETE ON image)
> 
> ...which is totally wrong.
> 
> I'm inclined to think that maybe we should leave that example as-is,
> and maybe add the variant you're proposing as a second example,
> showing how the basic version can be refined.

I have implemented this suggestion with the attached, applied patch to
9.3.

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

  + It's impossible for everything to be true. +

--ibTvN161/egqYuK8
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="lo.diff"

diff --git a/doc/src/sgml/lo.sgml b/doc/src/sgml/lo.sgml
new file mode 100644
index 3d56ba3..0c11fdc
*** a/doc/src/sgml/lo.sgml
--- b/doc/src/sgml/lo.sgml
*************** CREATE TRIGGER t_raster BEFORE UPDATE OR
*** 76,82 ****
    <para>
     For each column that will contain unique references to large objects,
     create a <literal>BEFORE UPDATE OR DELETE</> trigger, and give the column
!    name as the sole trigger argument.  If you need multiple <type>lo</>
     columns in the same table, create a separate trigger for each one,
     remembering to give a different name to each trigger on the same table.
    </para>
--- 76,90 ----
    <para>
     For each column that will contain unique references to large objects,
     create a <literal>BEFORE UPDATE OR DELETE</> trigger, and give the column
!    name as the sole trigger argument.  You can also restrict the trigger
!    to only execute on updates to the column with:
! 
! <programlisting>
! CREATE TRIGGER t_raster BEFORE UPDATE OF raster OR DELETE ON image
!     FOR EACH ROW EXECUTE PROCEDURE lo_manage(raster);
! </programlisting>
! 
!    If you need multiple <type>lo</>
     columns in the same table, create a separate trigger for each one,
     remembering to give a different name to each trigger on the same table.
    </para>

--ibTvN161/egqYuK8--