Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function
Date
Msg-id 8e2dbb701001091134t55574ea6w40c8b10e4b5c32f7@mail.gmail.com
Whole thread Raw
In response to Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2010/1/9 Tom Lane <tgl@sss.pgh.pa.us>:
> Dean Rasheed <dean.a.rasheed@googlemail.com> writes:
>>> ERROR:  attribute number -1 exceeds number of columns 1
>
> I guess your previous message slipped through the cracks --- sorry about
> that.  It looks like the best fix is to teach ExecEvalFieldSelect that
> references to system columns are OK.  Working on it now.
>

I wonder if it might be better to have plpgsql_parse_dblword() ignore
plpgsql_LookupIdentifiers, and always do the lookups. In addition to
fixing my original gripe, the resulting parse tree is simpler and slightly
faster to execute. Admittedly you have to work quite hard to contrive a
test case where the performance difference is noticeable, but with the
test code below patching plpgsql_parse_dblword() gives around a 4%
performance boost to the INSERT.

create table foo (val text, len int);

create or replace function foo_trig_fn() returns trigger as $$
begin new.len := length(new.val); return new;
end
$$ language plpgsql;

create trigger foo_trig before insert on foo for each row execute procedure foo_trig_fn();

insert into foo(val) select repeat('X', 100000000) from generate_series(1,10);

Regards,
Dean


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: maintenance announcement for dekeni.postgresql.org and minshara.postgresql.org
Next
From: Markus Wanner
Date:
Subject: Re: synchronized snapshots