Skip site navigation (1) Skip section navigation (2)

Re: [SQL] pl/PgSQL, variable names in NEW

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Martin Edlman <edlman(at)fortech(dot)cz>
Cc: pgsql-sql(at)postgresql(dot)org, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pg Docs <pgsql-docs(at)postgresql(dot)org>, andrew(at)dunslane(dot)net
Subject: Re: [SQL] pl/PgSQL, variable names in NEW
Date: 2008-04-10 13:16:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-docspgsql-hackerspgsql-sql
Martin Edlman wrote:

> |> I don't want to rewrite whole trigger to plPerl as I would have to use
> |> DBD-PgSPI.
> |
> | Huh?  Certainly not -- there are functions in PL/Perl for this.  See
> | spi_exec_query in
> |
> Oh, I see. I have read the doc "...can be done via the function
> spi_exec_query described below, or via an experimental module
> DBD::PgSPI...", but missed the "OR" and thought that DBD::PgSPI is
> mandatory.

Yeah, that's a bit confusing.  I don't know why we have a mention of
DBD::PgSPI on the plperl manual at all.  Is there anything it can do
that can't be done with PL/Perl native calls?

Question for plperl hackers:  Should we remove the mention of DBD::PgSPI
from the PL/Perl manual?

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-docs by date

Next:From: Alvaro HerreraDate: 2008-04-10 13:35:56
Subject: Re: Patch for pg_backend_pid
Previous:From: Martin EdlmanDate: 2008-04-10 11:34:06
Subject: Re: pl/PgSQL, variable names in NEW

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-04-10 13:24:34
Subject: Re: Separate psql commands from arguments
Previous:From: Alvaro HerreraDate: 2008-04-10 13:00:16
Subject: Re: Commit fest queue

pgsql-sql by date

Next:From: Tom LaneDate: 2008-04-10 14:45:25
Subject: Re: [HACKERS] [SQL] pl/PgSQL, variable names in NEW
Previous:From: Volkan YAZICIDate: 2008-04-10 12:37:13
Subject: Re: dateformat issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group