Andres Freund <andres@xxxxxxxxxxx> writes: > On 2015-10-09 14:32:44 +0800, Victor Blomqvist wrote: >> CREATE FUNCTION select_users(id_ integer) RETURNS SETOF users AS >> $$ >> BEGIN >> RETURN QUERY SELECT * FROM users WHERE id = id_; >> END; >> $$ LANGUAGE plpgsql; > My guess is that the problem here is that table level locking prevents > modification of the "users" type when the table is used, but there's no > locking preventing the columns to be dropped while the function is > used. So what happens is that 1) the function is parsed & planned 2) > DROP COLUMN is executed 3) the contained statement is executed 4) a > mismatch between the contained statement and the function definition is > detected. The query plan as such does get refreshed, I believe. The problem is that plpgsql has no provision for the definition of a named composite type to change after a function's been parsed. This applies to variables of named composite types for sure, and based on this example I think it must apply to the function result type as well, though I'm too lazy to go check the code right now. We have had past discussions about fixing this. I believe it would require getting rid of use of plpgsql's "row" infrastructure for named composites, at least in most cases, and going over to the "record" infrastructure instead. In the past the conversations have stalled as soon as somebody complained that that would probably make some operations slower. I don't entirely understand that objection, since (a) some other operations would probably get faster, and (b) performance does not trump correctness. But that's where the discussion stands at the moment. 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
