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

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Roger Curley <rocurley(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org>
Subject: Re: BUG #15623: Inconsistent use of default for updatable view
Date: 2019-02-13 09:33:05
Message-ID: 6c95c84f-3607-11ee-b279-16bec92885ec@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2019/02/13 18:04, Dean Rasheed wrote:
> 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.

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Francisco Olarte 2019-02-13 12:57:03 Re: Re[2]: BUG #15626: Incorrect version number shown in BigSQL installation
Previous Message Dean Rasheed 2019-02-13 09:04:40 Re: BUG #15623: Inconsistent use of default for updatable view

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2019-02-13 09:52:27 Re: 2019-02-14 Press Release Draft
Previous Message Dean Rasheed 2019-02-13 09:04:40 Re: BUG #15623: Inconsistent use of default for updatable view