On Tue, Apr 28, 2015 at 3:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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.
I don't know whether that would help or not. I was thinking about whether PLs should be using CacheRegisterSyscacheCallback() to notice when types that they care about change. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
