On 2017-03-28 15:24:28 -0400, Tom Lane wrote: > I wrote: > > Andres Freund <and...@anarazel.de> writes: > >> On 2017-03-28 14:43:38 -0400, Tom Lane wrote: > >>> 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? > > > Yeah, I'll go do that. > > Or maybe not: turns out we have regression test cases that depend on this > behavior, cf the bit in create_view.sql about > > -- this perhaps should be rejected, but it isn't: > alter table tt14t drop column f3; > -- f3 is still in the view but will read as nulls > > You'd proposed changing that, which I agree with in principle, but > I thought your patch wasn't right. Maybe we need to work harder on > that. > > (I'm not actually sure right at the moment why this case isn't failing > in HEAD. Maybe plpgsql is replacing the dropped column with nulls in > its result rows, so that whether the outer query special-cases them or > not doesn't affect the visible output.) > > Or we could just throw an error anyway. I'm not sure there's any > strong reason to allow such cases to work. I think the regression > tests were only put there to ensure they don't crash, not to memorialize > behavior we consider essential.
Yea, cases like that was what I was referring to with changing behaviour - I think it's ok to error out, as long as we do so reliably. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
