Re: postgres_fdw: evaluate placeholdervars on remote server

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw: evaluate placeholdervars on remote server
Date: 2017-09-15 20:20:01
Message-ID: 2CB97DF0-07F6-4080-B74B-C345891DEEFF@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 15 Sep 2017, at 17:19, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Sep 15, 2017 at 10:15 AM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>> Have you had a chance to look at this such that we can expect a rebased version
>> of this patch during the commitfest?
>
> Frankly, I think things where there was a ping multiple weeks before
> the CommitFest started and no rebase before it started should be
> regarded as untimely submissions, and summarily marked Returned with
> Feedback. The CommitFest is supposed to be a time to get things that
> are ready before it starts committed before it ends. Some amount of
> back-and-forth during the CF is of course to be expected, but we don't
> even really have enough bandwidth to deal with the patches that are
> being timely updated, never mind the ones that aren’t.

I don’t necessarily disagree with this, and especially not the part about
bandwidth which is absolutely correct.

What has happened a lot however is that these patches have been moved to the
next CF, and possibly the next from there. In that scenario, if we can get the
patches rebased now they wont be in a worse state when pushed to the next
compared to if they bitrot further. That being said, perhaps we should move
closer to a model like what you describe, but thats for another thread to
discuss rather than threadjacking this one more IMO.

cheers ./daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-09-15 20:36:32 Re: More efficient truncation of pg_stat_activity query strings
Previous Message Bruce Momjian 2017-09-15 20:17:52 Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)