Re: patch: function xmltable
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Craig Ringer <craig@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-24T22:37:44Z
Lists: pgsql-hackers
Hi, On 2017-01-24 17:38:49 -0300, Alvaro Herrera wrote: > +static Datum ExecEvalTableExpr(TableExprState *tstate, ExprContext *econtext, > + bool *isnull); > +static Datum ExecEvalTableExprFast(TableExprState *exprstate, ExprContext *econtext, > + bool *isNull); > +static Datum tabexprFetchRow(TableExprState *tstate, ExprContext *econtext, > + bool *isNull); > +static void tabexprInitialize(TableExprState *tstate, ExprContext *econtext, > + Datum doc); > +static void ShutdownTableExpr(Datum arg); To me this (and a lot of the other code) hints quite strongly that expression evalution is the wrong approach to implementing this. What you're essentially doing is building a vulcano style scan node. Even if we can this, we shouldn't double down on the bad decision to have these magic expressions that return multiple rows. There's historical reason for tSRFs, but we shouldn't add more weirdness like this. Andres
Commits
-
Support XMLTABLE query expression
- fcec6caafa23 10.0 landed
-
Create <sect3> in the functions-xml section
- 4461a9bfd1ac 10.0 landed
-
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
- 906bfcad7ba7 10.0 cited
-
Add xmlexists function
- 641459f26954 9.1.0 cited