Victor Blomqvist <vb@xxxxxxxx> writes: > In case any of you are interested of recreating this problem, I today had > the time to create a short example that reproduce the error every time I > try. Hmm. If you just do that serially: regression=# select * from select_a() ; id | x ----+--- (0 rows) regression=# alter table a add column y text; ALTER TABLE regression=# select * from select_a() ; id | x | y ----+---+--- (0 rows) regression=# alter table a drop column y; ALTER TABLE regression=# select * from select_a() ; id | x ----+--- (0 rows) So actually, we *are* tracking the change of table rowtype, both at the level of the query inside the function and at the level of the function result. The problem is that the instant at which the result rowtype of the function is determined (while parsing the outer query) is different from the instant at which the inner query's result rowtype is determined. I'm not really sure that there's anything we can, or even should, try to do about this. There would be a whole lot of action-at-a-distance involved and it would be likely to make some other use-cases worse. A possible user-level answer if you need to make an application robust against this sort of thing is to take out a low-grade lock on the table that's determining the function's result type: begin; lock table a in access share mode; select * from select_a(); commit; Holding the table lock will prevent any other transactions from altering the table's rowtype while this transaction runs. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
