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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
