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>, Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | 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 03:02:25 |
Message-ID: | fa629211-4476-6dcd-25fe-963e7b84cf88@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Hi Dean,
On 2019/02/12 19:33, Dean Rasheed wrote:
> On Sun, 10 Feb 2019 at 11:18, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>> On Sun, 10 Feb 2019 at 00:48, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>>> 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.
>>>
>>
>> Here's an updated patch to handle that case.
>>
>> In case it's not obvious, I'm not intending to try to get this into
>> next week's updates -- more time is needed to be sure of this fix.
>
> So I did some more testing of this and I'm reasonably happy that this
> now fixes the originally reported issue of inconsistent handling of
> DEFAULTS in multi-row VALUES lists vs single-row ones. I tested
> various other scenarios involving conditional/unconditional
> also/instead rules, and I didn't find any other surprises. Attached is
> an updated patch with improved comments, and a little less code
> duplication.
Thanks for updating the patch.
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?
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-02-13 03:58:35 | Re: 'update returning *' returns 0 columns instead of empty row with 2 columns when (i) no rows updated and (ii) when applied to a partitioned table with sub-partition |
Previous Message | Michael Paquier | 2019-02-13 02:38:17 | Re: BUG #15631: Generated as identity field in a temporary table with on commit drop corrupts system catalogs |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2019-02-13 03:10:32 | Re: Should we still have old release notes in docs? |
Previous Message | Jonathan S. Katz | 2019-02-13 03:00:15 | 2019-02-14 Press Release Draft |