From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cache invalidation for PL/pgsql functions |
Date: | 2015-04-28 19:59:11 |
Message-ID: | 34415.1430251151@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# create or replace function test (x foo) returns int as $$begin
> return x.b; end$$ language plpgsql;
> CREATE FUNCTION
> rhaas=# alter table foo add column b int;
> ALTER TABLE
> rhaas=# select test(null::foo);
> ERROR: record "x" has no field "b"
> LINE 1: SELECT x.b
> ^
> QUERY: SELECT x.b
> CONTEXT: PL/pgSQL function test(foo) line 1 at RETURN
I believe that this was one of the cases I had in mind when I previously
proposed that we stop using PLPGSQL_DTYPE_ROW entirely for composite-type
variables, and make them use PLPGSQL_DTYPE_REC (that is, the same code
paths used for RECORD).
As I recall, that proposal was shot down with no investigation whatsoever,
on the grounds that it might possibly make some cases slower.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2015-04-28 20:05:16 | Re: improving speed of make check-world |
Previous Message | Tom Lane | 2015-04-28 19:50:04 | Re: FIX : teach expression walker about RestrictInfo |