Re: polymorphic table functions light

> On 24 Jan 2020, at 08:27, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>
> I definitely want to make it work in a way that does not require writing C code.  My idea was to create a new type,
perhapscalled "descriptor", that represents essentially a tuple descriptor.  (It could be exactly a TupleDesc, as this
patchdoes, or something similar.)  For the sake of discussion, we could use JSON as the text representation of this.
Thena PL/pgSQL function or something else high level could easily be written to assemble this.  Interesting use cases
arefor example in the area of using PL/Perl or PL/Python for unpacking some serialization format using existing modules
inthose languages. 

I do think it’s very desirable to make it usable outside of C code.

> Obviously, there is a lot of leg work to be done between here and there, but it seems doable.  The purpose of this
initialpatch submission was to get some opinions on the basic idea of "determine result tuple structure by calling
helperfunction at parse time", and so far no one has fallen off their chair from that, so I'm encouraged. ;-) 

I’m interested in this development, as it makes RECORD-returning SRFs in the SELECT list a viable proposition, and that
inturn allows a ValuePerCall SRF to get meaningful benefit from pipelining. (They could always pipeline, but there is
noway to extract information from the RECORD that’s returned, with the sole exception of row_to_json.) 

I couldn’t check out that it would work though because I couldn’t apply the v2 (or v1) patch against either 12.0 or
530609a(which I think was sometime around 25th Jan). Against 12.0, I got a few rejections (prepjointree.c and
clauses.c).I figured they might be inconsequential, but no: initdb then fails at CREATE VIEW pg_policies. Different
rejectionsagainst 530609a, but still initdb fails. 

But I’m definitely very much encouraged.

denty.