Date: Tue, 28 Mar 2017 12:28:45 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Protection lost in expression eval changeover
Message-ID: <20170328192845.kfd7yp7vt44vuofa@alap3.anarazel.de>
References: <16803.1490723570@sss.pgh.pa.us>
 <20170328181324.e47nypa4vqg3dpk4@alap3.anarazel.de>
 <19025.1490726618@sss.pgh.pa.us>
 <20170328185104.yxs2ewbmb5wl4la7@alap3.anarazel.de>
 <19433.1490727242@sss.pgh.pa.us>
 <22347.1490729068@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <22347.1490729068@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers