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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 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-10 00:48:12
Message-ID: CAEZATCXTg_gxzf86+eTyLzJCY3OACQ71Wo_TPaeZyNAuo7frOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sat, 9 Feb 2019 at 16:57, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Fri, Feb 8, 2019 at 8:01 PM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> > On Fri, 8 Feb 2019 at 05:07, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > > Looking into this, the reason it works when inserting just one row vs.
> > > more than one row is that those two cases are handled by nearby but
> > > different pieces of code. The code that handles multiple rows seems buggy
> > > as seen in the above example. Specifically, I think the bug is in
> > > rewriteValuesRTE() which is a function to replace the default placeholders
> > > in the input rows by the default values as defined for the target
> > > relation. It is called twice when inserting via the view -- first for the
> > > view relation and then again for the underlying table.
> >
> > Right, except when the view is trigger-updatable...
>
> Oops, I missed this bit. Updated the patch per your suggestion and
> expanded the test case to exercise this.
>

Unfortunately, that's still not quite right because it makes the
behaviour of single- and multi-row inserts inconsistent for
rule-updatable views. Attached is an updated patch that fixes that. I
adjusted the tests a bit to try to make it clearer which defaults get
applied, and test all possibilities.

However, this is still not the end of the story, because it doesn't
fix the fact that, if the view has a DO ALSO rule on it, single-row
inserts behave differently from multi-row inserts. In that case, each
insert becomes 2 inserts, and defaults need to be treated differently
in each of the 2 queries. That's going to need a little more thought.

Regards,
Dean

Attachment Content-Type Size
view-insert-null-default-fix-v3.patch application/octet-stream 13.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-02-10 07:10:23 BUG #15626: Incorrect version number shown in BigSQL installation
Previous Message Tom Lane 2019-02-09 23:38:56 Re: BUG #15625: 10.6.1 Can't Find hstore.

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-02-10 01:16:54 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Previous Message Tomas Vondra 2019-02-10 00:25:37 Re: libpq compression