Eric Thinnes <e.thinnes@gmx.de> writes:
> The function always delivers the same result with the same call
> parameters except for the determination of the result types and the
> generation of the TupleDesc, the function has no side effects.
BlessTupleDesc certainly has side effects; that's pretty much the
whole point of it. If you're marking this thing as parallel safe,
I imagine that the problem boils down to "parallel worker locally
registers a blessed tupdesc, but the leader has never heard of it,
so fails to interpret the returned tuple".
Perhaps a workaround is possible by using a named composite type
instead of generating a rowtype on the fly? But that won't work
if you want this to be polymorphic.
Also, I recall that there are provisions in typcache.c in recent
versions to support a shared pool of registered (i.e. blessed)
tuple descriptors. That would likely solve your problem, but
I've never looked into how to use that code. I doubt just
calling BlessTupleDesc is enough. In particular, I imagine
you need to make sure the leader process creates the tupdesc
first, so it's available to all workers.
regards, tom lane