On 2017-03-28 14:43:38 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-28 13:52:50 -0400, Tom Lane wrote: > >> So it seems like we are missing some needed protection. I'm inclined > >> to think that it'd be all right to just throw an error immediately in > >> CheckVarSlotCompatibility if the target column is dropped. > > > Hm - so far we've pretty widely only set columns to NULL in that > > case. You don't see concerns with triggering errors in cases we > > previously hadn't? > > Well, in principle these errors ought to be unreachable at all; they're > only there to backstop any possible failure to notice stale plans.
Not entirely - e.g. I think some of that's reachable when composite types are involved. But it's probably ok to error out anyway. > I don't see a strong reason why we need to allow a dropped column to go > to null while we throw an immediate error for a change in column type. > (If there is some reason, hopefully beta testing will find it.) Ok. You're doing that? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
