Re: partition routing layering in nodeModifyTable.c

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, amitdkhan(dot)pg(at)gmail(dot)com
Subject: Re: partition routing layering in nodeModifyTable.c
Date: 2019-08-03 19:45:47
Message-ID: CAPmGK16-atJSpqY97qK=eA8WWO3gpA9QEZoTh2rVAu-CTE9mqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, Aug 4, 2019 at 3:03 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
> > >> What API does that function break?
> >
> > > You need to call it, whereas previously you did not need to call it. The
> > > effort to change an FDW to get one more parameter, or to call that
> > > function is about the same.

I got the point.

> > If those are the choices, adding a parameter is clearly the preferable
> > solution, because it makes the API breakage obvious at compile.
>
> Right. I think it's a *bit* less clear in this case because we'd also
> remove the field that such FDWs with direct modify support would use
> now (EState.es_result_relation_info).
>
> But I think it's also just plainly a better API to use the
> parameter. Even if, in contrast to the BeginDirectModify at hand,
> BeginForeignModify didn't already accept it. Requiring a function call to
> gather information that just about every realistic implementation is
> going to need doesn't make sense.

Agreed.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-08-03 21:04:16 Re: A couple of random BF failures in kerberosCheck
Previous Message Andres Freund 2019-08-03 19:37:33 Re: Unused header file inclusion