On 2019-12-16 22:13, Tom Lane wrote:
Hm. Given that this involves a function-taking-and-returning-internal, I think it's fairly silly to claim that it is implementing a SQL-standard feature, or even a subset or related feature. Nor do I see a pathway whereby this might end in a feature you could use without writing C code.
I think we'd be better off to address this by extending the existing "support function" infrastructure by inventing a new support request type,
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, perhaps called "descriptor", that represents essentially a tuple descriptor. (It could be exactly a TupleDesc, as this patch does, or something similar.) For the sake of discussion, we could use JSON as the text representation of this. Then a PL/pgSQL function or something else high level could easily be written to assemble this. Interesting use cases are for example in the area of using PL/Perl or PL/Python for unpacking some serialization format using existing modules in those languages.
The SQL standard has the option of leaving the call signatures of the PTF support functions implementation defined, so this approach would appear to be within the spirit of the specification.
Obviously, there is a lot of leg work to be done between here and there, but it seems doable. The purpose of this initial patch submission was to get some opinions on the basic idea of "determine result tuple structure by calling helper function at parse time", and so far no one has fallen off their chair from that, so I'm encouraged. ;-)
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
