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