Re: ExecMakeTableFunctionResult vs. pre-evaluated functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ExecMakeTableFunctionResult vs. pre-evaluated functions
Date
Msg-id 29186.1038774592@sss.pgh.pa.us
Whole thread Raw
In response to Re: ExecMakeTableFunctionResult vs. pre-evaluated functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Joe Conway <mail@joeconway.com> writes:
>> If presented with a non-function-call expression tree, can we always evaluate
>> it to produce a scalar constant (if it isn't already)? If so, why not do that,
>> create a one row, one column tuplestore, and exit? It's really no different 
>> than a function call that does the same, is it?

> Yeah, that's probably a reasonable approach to take.  It would fail if
> we had an expression that returned a non-scalar value (viz. a set),
> but the constant-folder won't try to fold or inline anything that
> returns a set, so you shouldn't see any problem in practice.

Actually, it turns out to be easy to make ExecMakeTableFunctionResult
cope with expressions returning sets as well.  It's the same as the
ValuePerCall protocol we defined for table functions (no surprise,
since that protocol was deliberately modeled on the existing
implementation of set-returning expressions).  So it's done.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: tsearch thoughts
Next
From: Hans-Jürgen Schönig
Date:
Subject: Why not add PostGIS to the core?