Re: BUG #15623: Inconsistent use of default for updatable view
От | Dean Rasheed |
---|---|
Тема | Re: BUG #15623: Inconsistent use of default for updatable view |
Дата | |
Msg-id | CAEZATCXTg_gxzf86+eTyLzJCY3OACQ71Wo_TPaeZyNAuo7frOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15623: Inconsistent use of default for updatable view (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: BUG #15623: Inconsistent use of default for updatable view
|
Список | pgsql-bugs |
On Sat, 9 Feb 2019 at 16:57, Amit Langote <amitlangote09@gmail.com> wrote: > On Fri, Feb 8, 2019 at 8:01 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > On Fri, 8 Feb 2019 at 05:07, Amit Langote <Langote_Amit_f8@lab.ntt.co.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
Вложения
В списке pgsql-bugs по дате отправления: