Re: BUG #15623: Inconsistent use of default for updatable view

On Wed, 13 Feb 2019 at 03:02, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> I can't really comment on all of the changes that that you made
> considering various cases, but became curious if the single-row and
> multi-row inserts cases could share the code that determines if the
> DEFAULT item be replaced by the target-relation-specified default or NULL?
> IOW, is there some reason why we can't avoid the special handling for the
> multi-row (RTE_VALUES) case?
>

No, not as far as I can see.

The tricky part for a multi-row insert is working out what to do when
it sees a DEFAULT, and there is no column default on the target
relation. For an auto-updatable view, it needs to leave the DEFAULT
untouched, so that it can later apply the base relation's column
default when it recurses. For all other kinds of relation, it needs to
turn the DEFAULT into a NULL.

For a single-row insert, that's all much easier. If it sees a DEFAULT,
and there is no column default, it simply omits that entry from the
targetlist. If it then recurses to the base relation, it will put the
targetlist entry back in, if the base relation has a column default.
So it doesn't need to know locally whether it's an auto-updatable
view, and the logic is much simpler. The multi-row case can't easily
do that (add and remove columns) because it's working with a
fixed-width table structure.

Actually, that's not quite the end of it. So far, this has only been
considering INSERT's. I think there are more issues with UPDATE's, but
that's a whole other can of worms. I think I'll commit this first, and
start a thread on -hackers to discuss that.

Regards,
Dean