Craig Ringer <cr...@2ndquadrant.com> writes: > On 7 April 2017 at 00:54, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers