I wrote: > [ dropping and recreating a composite type confuses plpgsql ] > That's not very nice. What's worse is that it works cleanly in v10, > making this a regression, no doubt caused by the hacking I did on > plpgsql's handling of composite variables.
After further poking, I've concluded that it's largely chance that I tried an example that works in v10, because a lot of related cases don't. This particular test case only accesses the record's fields by name, and in the PLPGSQL_DTYPE_ROW code paths those are compiled into separate scalar variables that are still valid even though an access to the whole record would fail. I'm dubious that it's a common use-case to create a composite variable that is only used as if it were a set of independent variables. Also, you can get similar failures by dropping and recreating other sorts of user-defined types, not just composites, and those errors go way back. So, if we were to do something about this, I think it ought to involve recompiling the function if it contains any reference to a user-defined type that got dropped since last time; that's not specific to composite variables. Maybe that's something we'll get motivated to do someday ... but I'm not sure how to do it without taking a performance hit for checking for the situation, and in any case it seems like new development not something to tackle in late beta. So I'm now inclined to withdraw this as an open item. On the other hand, it is a bit worrisome that I happened to hit on a case that worked better before. Maybe I'm wrong to judge this unlikely to happen in the field. Thoughts? regards, tom lane