| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: patch: function xmltable |
| Date: | 2017-01-24 22:37:44 |
| Message-ID: | 20170124223744.moyzln5vifjbkl7s@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-01-25 00:32:56 | Re: patch: function xmltable |
| Previous Message | Nikita Glukhov | 2017-01-24 22:25:01 | Re: PATCH: recursive json_populate_record() |