Re: Remaining 'needs review' patchs in July commitfest
От | Tom Lane |
---|---|
Тема | Re: Remaining 'needs review' patchs in July commitfest |
Дата | |
Msg-id | 21530.1438204135@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Remaining 'needs review' patchs in July commitfest (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Remaining 'needs review' patchs in July commitfest
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jul 28, 2015 at 3:51 PM, Heikki Linnakangas <hlinnaka@iki.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
В списке pgsql-hackers по дате отправления: