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

On 2019/02/13 18:04, Dean Rasheed wrote:
> On Wed, 13 Feb 2019 at 03:02, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.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.

Hmm yeah, column sets must be the same in in all value-lists.

> 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.

Sure, thanks for the explanation.

Regards,
Amit