public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Pavel Stehule <[email protected]>
Cc: Josh Kupershmidt <[email protected]>
Cc: pgsql-docs <[email protected]>
Subject: Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
Date: Wed, 15 Aug 2012 20:31:07 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFj8pRCfe6doaipkG7h_Pvr5vR0+4qArwxda7ZQTKruG5s0DfQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAK3UJRH+cQwHr9EBUYBx3VVhD6fur6v8w28PzjhWohNKYV-rbA@mail.gmail.com>
<CAFj8pRCfe6doaipkG7h_Pvr5vR0+4qArwxda7ZQTKruG5s0DfQ@mail.gmail.com>
On Wed, Sep 7, 2011 at 03:40:19PM +0200, Pavel Stehule wrote:
> 2011/9/7 Josh Kupershmidt <[email protected]>:
> > On Tue, Sep 6, 2011 at 10:54 PM, Bruce Momjian <[email protected]> wrote:
> >> Josh Kupershmidt wrote:
> >>> How about a doc tweak like the attached?
> >>
> >> Perfect. Applied to 9.0, 9.1, and head. Thanks. Sorry for the delay.
> >
> > Err, as Tom's first comment in this thread explains, Pavel and I were
> > both wrong: the variables in question are indeed NULL, not undefined.
> > I think the docs were fine the way they were.
>
> There is maybe bug - these variables are defined, but they has not
> assigned tupledesc, so there is not possible do any test
>
> postgres=# create table omega (a int, b int);
> CREATE TABLE
> postgres=# create or replace function foo_trig()
> postgres-# returns trigger as $$
> postgres$# begin
> postgres$# raise notice '%', new;
> postgres$# return null;
> postgres$# end;
> postgres$# $$ language plpgsql;
> CREATE FUNCTION
> postgres=# create trigger xxx after delete on omega for each row
> execute procedure foo_trig();
> CREATE TRIGGER
> postgres=# insert into omega values(20);
> INSERT 0 1
> postgres=# delete from omega;
> ERROR: record "new" is not assigned yet
> DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
> CONTEXT: PL/pgSQL function "foo_trig" line 3 at RAISE
>
> so current text in documentation is not correct too.
I used your queries to test NEW/OLD on DELETE/INSERT, respectively, and
for statement-level triggers, and you are right that they are
unassigned, not NULL.
The attached patch fixes our documentation for PG 9.3.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
[text/x-diff] null.diff (1.7K, 2-null.diff)
download | inline diff:
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
new file mode 100644
index ab40845..07fba57
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*************** RAISE unique_violation USING MESSAGE = '
*** 3403,3409 ****
<para>
Data type <type>RECORD</type>; variable holding the new
database row for <command>INSERT</>/<command>UPDATE</> operations in row-level
! triggers. This variable is <symbol>NULL</symbol> in statement-level triggers
and for <command>DELETE</command> operations.
</para>
</listitem>
--- 3403,3409 ----
<para>
Data type <type>RECORD</type>; variable holding the new
database row for <command>INSERT</>/<command>UPDATE</> operations in row-level
! triggers. This variable is unassigned in statement-level triggers
and for <command>DELETE</command> operations.
</para>
</listitem>
*************** RAISE unique_violation USING MESSAGE = '
*** 3415,3421 ****
<para>
Data type <type>RECORD</type>; variable holding the old
database row for <command>UPDATE</>/<command>DELETE</> operations in row-level
! triggers. This variable is <symbol>NULL</symbol> in statement-level triggers
and for <command>INSERT</command> operations.
</para>
</listitem>
--- 3415,3421 ----
<para>
Data type <type>RECORD</type>; variable holding the old
database row for <command>UPDATE</>/<command>DELETE</> operations in row-level
! triggers. This variable is unassigned in statement-level triggers
and for <command>INSERT</command> operations.
</para>
</listitem>
view thread (11+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox