| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remaining 'needs review' patchs in July commitfest |
| Date: | 2015-07-29 21:08:55 |
| Message-ID: | 21530.1438204135@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 28, 2015 at 3:51 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> plpgsql raise statement with context
>> Impasse. Everyone wants this feature in some form, but no consensus on
>> whether to do this client-side or server-side.
> +1 for server-side. Does anyone other than you even think that the
> client side is a reasonable way to go?
Yes. This is presupposing on the server side what the client will want
to display.
>>> dblink: add polymorphic result functions
>> Seems pretty ugly to me to add a dummy argument to functions, just so that
>> you can specify the result type. The problem it's trying to solve is real,
>> though. Should we take it as it is, or wait for some cleaner approach?
> +1 for take it. If we wait for something better, we may be waiting a long time.
-1. We have a clear design spec for a solution that fixes this for much
more than just dblink. I don't feel a need to paste on an ugly, single-use
band-aid in such a hurry. If we get close to 9.6 and there is no better
fix, we could reconsider; but now is not the time to give up on pursuing
the better solution.
>>> Asynchronous execution on postgres-fdw
>> If we're going to have some sort of general-purpose Parallel node support
>> soon, should we just forget about this? Or is it still useful? This adds a
>> fair amount of new infrastructure, for a fairly niche feature..
> IMHO, that's an extremely important feature. I believe that it will
> not be obsoleted by other parallelism work.
Again, this seems like rushing through a single-use band-aid while work
is still active on more general solutions. I think we should put this
off and see whether it makes sense *after* the general parallel query
stuff is (more nearly) functional. Even if it still makes sense then,
it may well need a rewrite.
> Actually, I think that
> some of the infrastructure that it introduces may be quite helpful for
> parallelism as well, but I haven't looked at in detail yet.
Then steal that stuff as and when you need it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2015-07-29 21:56:33 | Re: more RLS oversights |
| Previous Message | Alvaro Herrera | 2015-07-29 21:04:58 | Re: more RLS oversights |