Re: Protection lost in expression eval changeover
От | Andres Freund |
---|---|
Тема | Re: Protection lost in expression eval changeover |
Дата | |
Msg-id | 20170328185104.yxs2ewbmb5wl4la7@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Protection lost in expression eval changeover (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2017-03-28 14:43:38 -0400, Tom Lane wrote: > Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: