The following behavior surprised me, and a few other people at EnterpriseDB, and one of our customers:
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 rhaas=# \c You are now connected to database "rhaas" as user "rhaas". rhaas=# select test(null::foo); test ------
(1 row)
I hate to use the term "bug" for what somebody's probably going to tell me is acceptable behavior, but that seems like a bug. I guess the root of the problem is that PL/plgsql's cache invalidation logic only considers the pg_proc row's TID and xmin when deciding whether to recompile. For base types that's probably OK, but for composite types, not so much.
Thoughts?
It is inconsistent - and I know so one bigger Czech companies, that use Postgres, had small outage, because they found this issue, when deployed new version of procedure.
