Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function
Date: 2010-01-09 19:34:30
Message-ID: 8e2dbb701001091134t55574ea6w40c8b10e4b5c32f7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/1/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2010-01-09 19:37:32 Re: synchronized snapshots
Previous Message Robert Haas 2010-01-09 19:12:40 Re: damage control mode