On 2017-03-28 15:24:28 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@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
