Re: The flinfo->fn_extra question, from me this time.

> On 12 Mar 2020, at 18:51, Tom Lane wrote: > > […] > > I didn't want to spend any more effort on it than that, because I'm > not really on board with this line of attack. Appreciate that. It was about the approach that I was most keen to get feedback upon. > This patch seems > awfully invasi

Re: The flinfo->fn_extra question, from me this time.

On Fri, Mar 13, 2020 at 7:51 AM Tom Lane wrote: > ... (At least on the Linux side. I guess the cfbot's > Windows builds are sans cassert, which seems like an odd choice.) I tried turning that on by adding $config{asserts} = 1 in the build script and adding some scripting to dump all relevant lo

Re: The flinfo->fn_extra question, from me this time.

The cfbot is still not happy with this, because you're ignoring the project style rule against C99-like mixing of code and declarations. I went to fix that, and soon found that the code doesn't compile, much less pass regression tests, with --enable-cassert. That's really a serious error on your p

Re: The flinfo->fn_extra question, from me this time.

> On 28 Jan 2020, at 09:56, Thomas Munro wrote: > > ([…] I have no > idea what GUI interaction causes that, but most Apple Mail attachments > seem to be fine.) I gathered from the other thread that posting plain text seems to attach the patches in a way that’s more acceptable. Seems to work, b

Re: The flinfo->fn_extra question, from me this time.

On Tue, Jan 28, 2020 at 9:59 PM Dent John wrote: > I’ll look at it. Probably won’t be able to until after the commitfest closes > though. (We've seen that hidden attachment problem from Apple Mail before, discussion of the MIME details in the archives somewhere. I have no idea what GUI interact

Re: The flinfo->fn_extra question, from me this time.

Thanks Tom. I’ll look at it. Probably won’t be able to until after the commitfest closes though. d. > On 28 Jan 2020, at 02:58, Tom Lane wrote: > > Dent John writes: >> I’ve updated the patch, addressed the rescan issue, and restructured the >> tests. >> [ pipeline-functionscan-v4.patch

Re: The flinfo->fn_extra question, from me this time.

Dent John writes: > I’ve updated the patch, addressed the rescan issue, and restructured the > tests. > [ pipeline-functionscan-v4.patch ] FWIW, this patch doesn't apply to HEAD anymore. The cfbot has failed to notice because it is still testing the v3 patch. Apparently the formatting of this e

Re: The flinfo->fn_extra question, from me this time.

Hi folks,I’ve updated the patch, addressed the rescan issue, and restructured the tests.I’ve taken a slightly different approach this time, re-using the (already pipeline-supporting) machinery of the Materialize node, and extended it to allow an SFRM_Materialize SRF to donate the tuplestore it retu

Re: The flinfo->fn_extra question, from me this time.

>> On 3 Nov 2019, at 13:33, Pavel Stehule wrote: >> >> can be nice, if patch has some regress tests - it is good for memory >> refreshing what is target of patch. I’ve updated the patch, and added some regression tests. denty. pipeline-functionscan-v3.patch Description: Binary data

Re: The flinfo->fn_extra question, from me this time.

> On 3 Nov 2019, at 13:33, Pavel Stehule wrote: > > can be nice, if patch has some regress tests - it is good for memory > refreshing what is target of patch. With a suitably small work_mem constraint, it is possible to show the absence of buffers resulting from the tuplestore. It’ll need some

Re: The flinfo->fn_extra question, from me this time.

Hi ne 3. 11. 2019 v 12:51 odesílatel Dent John napsal: > (And here’s aforementioned attachment… doh.) > can be nice, if patch has some regress tests - it is good for memory refreshing what is target of patch. Regards Pavel

Re: The flinfo->fn_extra question, from me this time.

(And here’s aforementioned attachment… doh.) pipeline-functionscan-v2.patch Description: Binary data

Re: The flinfo->fn_extra question, from me this time.

Hi, Turns out — to my embarrassment — that pretty much all of the regression tests failed with my patch. No idea if anyone spotted that and withheld reply in revenge, but I wouldn’t blame if you did! I have spent a bit more time on it. The attached patch is a much better show, though there are

Re: The flinfo->fn_extra question, from me this time.

On 22 Sep 2019, at 16:01, Tom Lane wrote:Hi Tom,I don't know of anybody working on it.Okay. I had a look at this. I tried to apply Andre’s patch [1] from some time ago, but that turned out not so easy. I guess the code has moved on since. So I’ve attempted to re-invent the same

Re: The flinfo->fn_extra question, from me this time.

On Sun, Jul 21, 2019 at 5:55 PM Tom Lane wrote: > The FROM case could be improved perhaps, if somebody wanted to put > time into it. You'd still need to be prepared to build a tuplestore, > in case of rescan or backwards fetch; but in principle you could return > rows immediately while stashing t

Re: The flinfo->fn_extra question, from me this time.

Dent John writes: > On 21 Jul 2019, at 22:54, Tom Lane wrote: >> Chapman Flack writes: >>> But looking in the code, I'm getting the impression that those >>> benefits are only theoretical future ones, as ExecMakeTableFunctionResult >>> implements SFRM_ValuePerCall mode by ... repeatedly calling

Re: The flinfo->fn_extra question, from me this time.

On 21 Jul 2019, at 22:54, Tom Lane wrote: > > Chapman Flack writes: >> Until now, I had assumed that SFRM_ValuePerCall mode might offer some >> benefits, such as the possibility of pipelining certain queries and not >> building up a whole tuplestore in advance. > >> But looking in the code, I'm

Re: The flinfo->fn_extra question, from me this time.

Chapman Flack writes: > Until now, I had assumed that SFRM_ValuePerCall mode might offer some > benefits, such as the possibility of pipelining certain queries and not > building up a whole tuplestore in advance. > But looking in the code, I'm getting the impression that those > benefits are only

Re: The flinfo->fn_extra question, from me this time.

On 06/15/19 21:46, Chapman Flack wrote: > On 06/15/19 21:21, Tom Lane wrote: >> Yup. (Of course, you don't have to use the SRF_FIRSTCALL_INIT >> infrastructure.) > > That had crossed my mind ... but it seems there's around 80 or 100 > lines of good stuff there that'd be a shame to duplicate. If o

Re: The flinfo->fn_extra question, from me this time.

On 06/15/19 21:21, Tom Lane wrote: > Yup. (Of course, you don't have to use the SRF_FIRSTCALL_INIT > infrastructure.) That had crossed my mind ... but it seems there's around 80 or 100 lines of good stuff there that'd be a shame to duplicate. If only init_MultiFuncCall() took an extra void ** arg

Re: The flinfo->fn_extra question, from me this time.

Chapman Flack writes: > So please let me know if I seem to correctly understand the limits > on its use. > I gather that various extensions use it to stash various things. But > (I assume) ... they will only touch fn_extra in FmgrInfo structs that > pertain to *their own functions*. (Please say t

The flinfo->fn_extra question, from me this time.

Hi hackers, I see evidence on this list that it's sort of a rite of passage to ask the flinfo->fn_extra question, and my time has come. So please let me know if I seem to correctly understand the limits on its use. I gather that various extensions use it to stash various things. But (I assume) .