On 2017-03-28 15:24:28 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund 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
I wrote:
> Andres Freund 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
Andres Freund 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'
On 2017-03-28 14:43:38 -0400, Tom Lane wrote:
> Andres Freund 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
> >> CheckVarSlotCompatibili
Andres Freund 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
Hi,
On 2017-03-28 13:52:50 -0400, Tom Lane wrote:
> CheckVarSlotCompatibility contains the comment
>
>* Note: we allow a reference to a dropped attribute. slot_getattr will
>* force a NULL result in such cases.
>
> While still true, that second sentence is now quite irrelevant,
