Re: cache invalidation for PL/pgsql functions
От | Tom Lane |
---|---|
Тема | Re: cache invalidation for PL/pgsql functions |
Дата | |
Msg-id | 34415.1430251151@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | cache invalidation for PL/pgsql functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: cache invalidation for PL/pgsql functions
|
Список | 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 по дате отправления: