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
Date: Tue, 28 Mar 2017 12:28:45 -0700
Message-ID: <20170328192845.kfd7yp7vt44vuofa@alap3.anarazel.de> (raw)
In-Reply-To: <22347.1490729068@sss.pgh.pa.us>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us
Subject: Re: Protection lost in expression eval changeover
In-Reply-To: <20170328192845.kfd7yp7vt44vuofa@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox