On Tue, Jan 31, 2023 at 3:44 PM Fujii Masao wrote:
> On 2023/01/29 19:31, Etsuro Fujita wrote:
> > I agree that if the name of an existing function was bad, we should
> > rename it, but I do not think the name pgfdw_get_cleanup_result is
> > bad; I think it is good in the sense that it well repres
On 2023/01/29 19:31, Etsuro Fujita wrote:
I agree that if the name of an existing function was bad, we should
rename it, but I do not think the name pgfdw_get_cleanup_result is
bad; I think it is good in the sense that it well represents what the
function waits for.
The patch you proposed cha
Hi Fujii-san,
On Thu, Sep 15, 2022 at 12:17 AM Fujii Masao
wrote:
> On 2022/09/05 15:17, Etsuro Fujita wrote:
> > I'm not sure it's a good idea to change the function's name, because
> > that would make backpatching hard. To avoid that, how about
> > introducing a workhorse function for pgfdw_ge
On 2022/09/05 15:17, Etsuro Fujita wrote:
+1 for that refactoring. Here are a few comments about the 0001 patch:
Thanks for reviewing the patch!
I'm not sure it's a good idea to change the function's name, because
that would make backpatching hard. To avoid that, how about
introducing a
On Tue, Jul 26, 2022 at 4:25 PM Kyotaro Horiguchi
wrote:
> At Tue, 26 Jul 2022 00:54:47 +0900, Fujii Masao
> wrote in
> > There are two functions, pgfdw_get_result() and
> > pgfdw_get_cleanup_result(),
> > to get a query result. They have almost the same code, call
> > PQisBusy(),
> > WaitLatchO
On Thu, Jul 28, 2022 at 11:56 AM Fujii Masao
wrote:
>
>
>
> On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
> > At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
> > wrote in
> >>> I'm not sure the two are similar with each other. The new function
> >>> pgfdw_exec_pre_commit() looks like a merger o
At Thu, 28 Jul 2022 15:26:42 +0900, Fujii Masao
wrote in
>
>
> On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
> > At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
> > wrote in
> > I didn't see it from that viewpoint but I don't think that
> > unconditionally justifies other refactoring. If we
On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
wrote in
I'm not sure the two are similar with each other. The new function
pgfdw_exec_pre_commit() looks like a merger of two isolated code paths
intended to share a seven-line codelet. I feel t
On Tue, Jul 26, 2022 at 7:46 PM Fujii Masao wrote:
> On 2022/07/26 19:26, Etsuro Fujita wrote:
> > Could you add this to the next CF?
>
> Yes.
> https://commitfest.postgresql.org/39/3782/
Thanks!
Best regards,
Etsuro Fujita
At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
wrote in
> > I'm not sure the two are similar with each other. The new function
> > pgfdw_exec_pre_commit() looks like a merger of two isolated code paths
> > intended to share a seven-line codelet. I feel the code gets a bit
> > harder to unders
On 2022/07/26 19:26, Etsuro Fujita wrote:
Thanks for working on this! I'd like to review this after the end of
the current CF.
Thanks!
Could you add this to the next CF?
Yes.
https://commitfest.postgresql.org/39/3782/
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Rese
Fujii-san,
On Tue, Jul 26, 2022 at 12:55 AM Fujii Masao
wrote:
> When reviewing the postgres_fdw parallel-abort patch [1], I found that
> there are several duplicate codes in postgres_fdw/connection.c.
> Which seems to make it harder to review the patch changing connection.c.
> So I'd like to rem
On 2022/07/26 16:25, Kyotaro Horiguchi wrote:
Agree to that refactoring. And it looks fine to me.
Thanks for reviewing the patches!
I'm not sure the two are similar with each other. The new function
pgfdw_exec_pre_commit() looks like a merger of two isolated code paths
intended to share
At Tue, 26 Jul 2022 00:54:47 +0900, Fujii Masao
wrote in
> Hi,
>
> When reviewing the postgres_fdw parallel-abort patch [1], I found that
> there are several duplicate codes in postgres_fdw/connection.c.
> Which seems to make it harder to review the patch changing
> connection.c.
> So I'd like
14 matches
Mail list logo
