Re: cache invalidation for PL/pgsql functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: cache invalidation for PL/pgsql functions
Date
Msg-id 34415.1430251151@sss.pgh.pa.us
Whole thread Raw
In response to cache invalidation for PL/pgsql functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: cache invalidation for PL/pgsql functions
List pgsql-hackers
Robert Haas <robertmhaas@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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: FIX : teach expression walker about RestrictInfo
Next
From: Peter Eisentraut
Date:
Subject: Re: improving speed of make check-world