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

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: (view raw, whole thread or download thread mbox)
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 $$
  new.len := length(new.val);
  return new;
$$ 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);


In response to


pgsql-hackers by date

Next:From: Markus WannerDate: 2010-01-09 19:37:32
Subject: Re: synchronized snapshots
Previous:From: Robert HaasDate: 2010-01-09 19:12:40
Subject: Re: damage control mode

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