2015-04-28 19:43 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > 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. The question is what is a cost of fixing Regards Pavel > > -- > 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 >
