Andres Freund <andres@anarazel.de> 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