Craig Ringer <craig@2ndquadrant.com> writes:
> On 7 April 2017 at 00:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... External callers will only be
>> interested in the result of the canSetTag subquery.
> I wasn't aware that such queries could ever return a result set, though.
Possibly not, but the point is that they should be invisible to the
caller. As the patch is set up, I think they'd look like empty result
sets instead, because the passed-in DestReceiver is used for them.
What we want is to use DestNone for non-canSetTag queries, and either
DestSPI or the caller's receiver for the canSetTag query.
> Personally I think this patch should be allowed to bypass
> CreateDestReceiver and create its own struct. I don't really see that
> it should be required to clean up the whole API first.
Well, if you bypass CreateDestReceiver then the question is what you're
putting in mydest and whether anything will get confused by that. The
core problem with the existing API is that there's no provision for
adding new kinds of DestReceivers without a corresponding addition to
the CommandDest enum. I think we really need some non-kluge solution
to that before moving forward.
> It's on the pointy end for Pg10, and I thought we'd be fine to include
> this in pg10 then aim to clean up DestReceiver in early pg11, or even
> as a post-feature-freeze refactoring fixup in pg10. Should the
> callback approach be blocked because the API it has to use is a bit
> ugly?
Given Peter's objections, I don't think this is getting into v10 anyway,
so we might as well take a bit more time and do it right.
Also, I'm entirely -1 on "post-feature-freeze refactoring fixups".
We're going to have more than enough to do trying to stabilize the
existing committed code, I fear (cf Robert's pessimistic summary of
the open-items list, a couple days ago). We don't need to be
planning on doing new design post-freeze, whether it's painted as
mere refactoring or not.
regards, tom lane
