public inbox for [email protected]
help / color / mirror / Atom feeddocumentation bug - behave of NEW a OLD in plpgsql's triggers
11+ messages / 4 participants
[nested] [flat]
* documentation bug - behave of NEW a OLD in plpgsql's triggers
@ 2011-05-02 16:00 Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Pavel Stehule @ 2011-05-02 16:00 UTC (permalink / raw)
To: [email protected]
Hello
one czech user reported a bug in documentation -
http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html
NEW
Data type RECORD; variable holding the new database row for
INSERT/UPDATE operations in row-level triggers. This variable is NULL
in statement-level triggers and for DELETE operations.
OLD
Data type RECORD; variable holding the old database row for
UPDATE/DELETE operations in row-level triggers. This variable is NULL
in statement-level triggers and for INSERT operations.
It isn't correct. NEW is not declared in DELETE trigger, OLD isn't
declared in INSERT
Regards
Pavel Stehule
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
@ 2011-05-06 00:56 ` Josh Kupershmidt <[email protected]>
2011-05-06 02:31 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 02:36 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Tom Lane <[email protected]>
2011-09-07 02:54 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
0 siblings, 3 replies; 11+ messages in thread
From: Josh Kupershmidt @ 2011-05-06 00:56 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: pgsql-docs
[Moving to -docs]
On Mon, May 2, 2011 at 12:00 PM, Pavel Stehule <[email protected]> wrote:
> Hello
>
> one czech user reported a bug in documentation -
> http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html
>
> NEW
>
> Data type RECORD; variable holding the new database row for
> INSERT/UPDATE operations in row-level triggers. This variable is NULL
> in statement-level triggers and for DELETE operations.
> OLD
>
> Data type RECORD; variable holding the old database row for
> UPDATE/DELETE operations in row-level triggers. This variable is NULL
> in statement-level triggers and for INSERT operations.
>
> It isn't correct. NEW is not declared in DELETE trigger, OLD isn't
> declared in INSERT
If I've understood you correctly, the problem is that the docs claim
that the variables are defined with a value of NULL, when in fact they
are undefined. For example, if you try to use variable NEW in a delete
trigger, you'll get an error message like:
| ERROR: record "new" is not assigned yet
| DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
How about a doc tweak like the attached?
Josh
Attachments:
[text/x-patch] plpgsql_triggers.patch (1.7K, 2-plpgsql_triggers.patch)
download | inline diff:
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 1866e43..6b6cf37 100644
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*************** RAISE unique_violation USING MESSAGE = '
*** 3279,3286 ****
<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>
</varlistentry>
--- 3279,3286 ----
<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 not defined in statement-level triggers
! or <command>DELETE</command> operations.
</para>
</listitem>
</varlistentry>
*************** RAISE unique_violation USING MESSAGE = '
*** 3291,3298 ****
<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>
</varlistentry>
--- 3291,3298 ----
<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 not defined in statement-level triggers
! or <command>INSERT</command> operations.
</para>
</listitem>
</varlistentry>
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-05-06 02:31 ` Pavel Stehule <[email protected]>
2 siblings, 0 replies; 11+ messages in thread
From: Pavel Stehule @ 2011-05-06 02:31 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: pgsql-docs
Hello
2011/5/6 Josh Kupershmidt <[email protected]>:
> [Moving to -docs]
>
> On Mon, May 2, 2011 at 12:00 PM, Pavel Stehule <[email protected]> wrote:
>> Hello
>>
>> one czech user reported a bug in documentation -
>> http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html
>>
>> NEW
>>
>> Data type RECORD; variable holding the new database row for
>> INSERT/UPDATE operations in row-level triggers. This variable is NULL
>> in statement-level triggers and for DELETE operations.
>> OLD
>>
>> Data type RECORD; variable holding the old database row for
>> UPDATE/DELETE operations in row-level triggers. This variable is NULL
>> in statement-level triggers and for INSERT operations.
>>
>> It isn't correct. NEW is not declared in DELETE trigger, OLD isn't
>> declared in INSERT
>
> If I've understood you correctly, the problem is that the docs claim
> that the variables are defined with a value of NULL, when in fact they
> are undefined. For example, if you try to use variable NEW in a delete
> trigger, you'll get an error message like:
> | ERROR: record "new" is not assigned yet
> | DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
>
> How about a doc tweak like the attached?
it is correct
Regards
Pavel Stehule
>
> Josh
>
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-05-06 02:36 ` Tom Lane <[email protected]>
2011-05-06 02:58 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2011-05-06 02:36 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
Josh Kupershmidt <[email protected]> writes:
> [Moving to -docs]
> On Mon, May 2, 2011 at 12:00 PM, Pavel Stehule <[email protected]> wrote:
>> It isn't correct. NEW is not declared in DELETE trigger, OLD isn't
>> declared in INSERT
That claim is flat out wrong.
> If I've understood you correctly, the problem is that the docs claim
> that the variables are defined with a value of NULL, when in fact they
> are undefined. For example, if you try to use variable NEW in a delete
> trigger, you'll get an error message like:
> | ERROR: record "new" is not assigned yet
> | DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
That is, in fact, exactly the behavior you get if you declare a RECORD
variable and set it to NULL. If these variables were indeed not
declared, you'd get a complaint about "new" not being a known variable.
Observe:
regression=# create function foo(int) returns void as $$
regression$# begin
regression$# new.x := $1;
regression$# end$$ language plpgsql;
ERROR: "new.x" is not a known variable
LINE 3: new.x := $1;
^
versus
regression=# create function foo(int) returns void as $$
regression$# declare new record;
regression$# begin
regression$# new := null;
regression$# new.x := $1;
regression$# end$$ language plpgsql;
CREATE FUNCTION
regression=# select foo(1);
ERROR: record "new" is not assigned yet
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
CONTEXT: PL/pgSQL function "foo" line 5 at assignment
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-05-06 02:36 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Tom Lane <[email protected]>
@ 2011-05-06 02:58 ` Josh Kupershmidt <[email protected]>
2011-05-06 03:32 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Tom Lane <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Josh Kupershmidt @ 2011-05-06 02:58 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
On Thu, May 5, 2011 at 10:36 PM, Tom Lane <[email protected]> wrote:
> That is, in fact, exactly the behavior you get if you declare a RECORD
> variable and set it to NULL. If these variables were indeed not
> declared, you'd get a complaint about "new" not being a known variable.
Hrm, guess I learned something. I tested with a trigger function which used:
...
IF NEW IS NULL THEN
RAISE NOTICE 'new is null.';
...
which was giving me 'ERROR: record "new" is not assigned yet' when
used as an on-delete trigger. I am a little surprised that you can't
use IS NULL to test out a record-type variable which you've just
declared to be NULL, e.g. this function blows up:
CREATE OR REPLACE FUNCTION test_trg() RETURNS TRIGGER AS $$
DECLARE SOMEVAR record;
BEGIN
SOMEVAR := NULL;
IF SOMEVAR IS NULL THEN
RAISE NOTICE 'somevar is null.';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
with the same error message.
Josh
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-05-06 02:36 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Tom Lane <[email protected]>
2011-05-06 02:58 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-05-06 03:32 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Tom Lane @ 2011-05-06 03:32 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
Josh Kupershmidt <[email protected]> writes:
> Hrm, guess I learned something. I tested with a trigger function which used:
> ...
> IF NEW IS NULL THEN
> RAISE NOTICE 'new is null.';
> ...
> which was giving me 'ERROR: record "new" is not assigned yet' when
> used as an on-delete trigger.
Hmm ... I wonder whether we couldn't make that case work, since IS NULL
shouldn't particularly care whether the record has a known tuple
structure or not. Still, it's probably not worth spending effort on ...
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-09-07 02:54 ` Bruce Momjian <[email protected]>
2011-09-07 13:21 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2 siblings, 1 reply; 11+ messages in thread
From: Bruce Momjian @ 2011-09-07 02:54 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
Josh Kupershmidt wrote:
> [Moving to -docs]
>
> On Mon, May 2, 2011 at 12:00 PM, Pavel Stehule <[email protected]> wrote:
> > Hello
> >
> > one czech user reported a bug in documentation -
> > http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html
> >
> > NEW
> >
> > ? ?Data type RECORD; variable holding the new database row for
> > INSERT/UPDATE operations in row-level triggers. This variable is NULL
> > in statement-level triggers and for DELETE operations.
> > OLD
> >
> > ? ?Data type RECORD; variable holding the old database row for
> > UPDATE/DELETE operations in row-level triggers. This variable is NULL
> > in statement-level triggers and for INSERT operations.
> >
> > It isn't correct. NEW is not declared in DELETE trigger, OLD isn't
> > declared in INSERT
>
> If I've understood you correctly, the problem is that the docs claim
> that the variables are defined with a value of NULL, when in fact they
> are undefined. For example, if you try to use variable NEW in a delete
> trigger, you'll get an error message like:
> | ERROR: record "new" is not assigned yet
> | DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
>
> How about a doc tweak like the attached?
Perfect. Applied to 9.0, 9.1, and head. Thanks. Sorry for the delay.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-09-07 02:54 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
@ 2011-09-07 13:21 ` Josh Kupershmidt <[email protected]>
2011-09-07 13:24 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
2011-09-07 13:40 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Josh Kupershmidt @ 2011-09-07 13:21 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
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.
Josh
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-09-07 02:54 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
2011-09-07 13:21 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-09-07 13:24 ` Bruce Momjian <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: Bruce Momjian @ 2011-09-07 13:24 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: Pavel Stehule <[email protected]>; pgsql-docs
Josh Kupershmidt wrote:
> 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.
OK, reverted. I did not see Tom's comment.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-09-07 02:54 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
2011-09-07 13:21 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
@ 2011-09-07 13:40 ` Pavel Stehule <[email protected]>
2012-08-16 00:31 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: Pavel Stehule @ 2011-09-07 13:40 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-docs
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.
Regards
Pavel Stehule
>
> Josh
>
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Re: documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-09-07 02:54 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Bruce Momjian <[email protected]>
2011-09-07 13:21 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Josh Kupershmidt <[email protected]>
2011-09-07 13:40 ` Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
@ 2012-08-16 00:31 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Bruce Momjian @ 2012-08-16 00:31 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: Josh Kupershmidt <[email protected]>; pgsql-docs
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>
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2012-08-16 00:31 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-05-02 16:00 documentation bug - behave of NEW a OLD in plpgsql's triggers Pavel Stehule <[email protected]>
2011-05-06 00:56 ` Josh Kupershmidt <[email protected]>
2011-05-06 02:31 ` Pavel Stehule <[email protected]>
2011-05-06 02:36 ` Tom Lane <[email protected]>
2011-05-06 02:58 ` Josh Kupershmidt <[email protected]>
2011-05-06 03:32 ` Tom Lane <[email protected]>
2011-09-07 02:54 ` Bruce Momjian <[email protected]>
2011-09-07 13:21 ` Josh Kupershmidt <[email protected]>
2011-09-07 13:24 ` Bruce Momjian <[email protected]>
2011-09-07 13:40 ` Pavel Stehule <[email protected]>
2012-08-16 00:31 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox