Paul Ramsey writes:
> Thank the Maker, it is reproduceable: returning an expanded header in the _in
> function is not appreciated in a very narrow number of cases.
BTW, on further poking around: if you'd had RANDOMIZE_ALLOCATED_MEMORY
enabled, returning an expanded object from an input function
I wrote:
> Paul Ramsey writes:
>> Thank the Maker, it is reproduceable: returning an expanded header in
>> the _in function is not appreciated in a very narrow number of cases.
> Thanks for finding a test case! I'll check into it shortly.
So the short answer is that the planner assumes, not unr
Paul Ramsey writes:
> Thank the Maker, it is reproduceable: returning an expanded header in the _in
> function is not appreciated in a very narrow number of cases.
Thanks for finding a test case! I'll check into it shortly.
regards, tom lane
--
Sent via pgsql-hackers
Thank the Maker, it is reproduceable: returning an expanded header in the _in
function is not appreciated in a very narrow number of cases.
Edit arrayfuncs.c:array_in(), change the return line thus:
// PG_RETURN_ARRAYTYPE_P(retval);
PG_RETURN_DATUM(expand_array(PointerGetDatum(re
Paul Ramsey writes:
> Since youâre not seeing anything âahaâ in the error pattern, Iâll go
> back to the mats on memory⦠is there a good page on valgriding postgresql?
https://wiki.postgresql.org/wiki/Valgrind
> I thought the memory manager papered over things so much that valgrind
>
I have a size/flatten callback setup (and they are very careful not to write
outside their boundaries), so that’s all OK.
Since you’re not seeing anything “aha” in the error pattern, I’ll go back to
the mats on memory… is there a good page on valgriding postgresql? I thought
the memory manager
Paul Ramsey writes:
> So, I've added support for converting postgis in-memory objects into
> expanded outputs, and have overwritten the usual
> lwgeom_to_gserialized() function with one that creates an expanded
> object. I haven't done anything to actually handle expanded objects on
> input, but a
I'm starting to think this might not actually be my mistake, but be a
very narrow issue w/ the expanded object code.
So, I've added support for converting postgis in-memory objects into
expanded outputs, and have overwritten the usual
lwgeom_to_gserialized() function with one that creates an expan