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
