| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c) |
| Date: | 2022-12-23 03:29:56 |
| Message-ID: | CA+HiwqHnrM2PLW2c49EK5-JnvgiBEnonZDhqr=SrtyVmWr+i6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 23, 2022 at 12:22 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> Attached shows a test case I was able to come up with that I can see
> is broken by a61b1f74 though passes after applying Richard's patch.
BTW, I couldn't help but notice in the output of the test case I wrote
that a generated column of a foreign table is not actually generated
locally, neither when inserting into the foreign table nor when
updating it, so it is left NULL when passing the NEW row to the remote
server. Behavior is the same irrespective of whether the
insert/update is performed directly on the foreign table or indirectly
via an insert/update on the parent. If that's documented behavior of
postgres_fdw, maybe we are fine, but just wanted to mention that it's
not related to the bug being discussed here.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-12-23 03:36:14 | Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c) |
| Previous Message | Justin Pryzby | 2022-12-23 03:27:24 | Re: [BUG] pg_upgrade test fails from older versions. |