Re: Inline non-SQL SRFs using SupportRequestSimplify

On 7/26/24 11:58, Tom Lane wrote:
 > Heikki Linnakangas <hlinnaka@iki.fi> writes:
 >> On 28/06/2024 01:01, Paul Jungwirth wrote:
 >>> Another approach I considered is using a separate support request, e.g. 
SupportRequestInlineSRF, and
 >>> just calling it from inline_set_returning_function. I didn't like having two support requests that
 >>> did almost exactly the same thing. OTOH my current approach means you'll get an error if you do 
this:
 >>>
 >>> ```
 >>> postgres=# select temporal_semijoin('employees', 'id', 'valid_at', 'positions', 'employee_id',
 >>> 'valid_at');
 >>> ERROR:  unrecognized node type: 66
 >>> ```
 >>>
 >>> I'll look into ways to fix that.
 >
 > I like this idea, but I like exactly nothing about this implementation.
 > The right thing is to have a separate SupportRequestInlineSRF request
 > that is called directly by inline_set_returning_function.

Here are new patches using a new SupportRequestInlineSRF request type. They include patches and 
documentation.

The patches handle this:

    SELECT * FROM srf();

but not this:

    SELECT srf();

In the latter case, Postgres always calls the function in "materialized mode" and gets the whole 
result up front, so inline_set_returning_function is never called, even for SQL functions.

For tests I added a `foo_from_bar(colname, tablename, filter)` PL/pgSQL function that does `SELECT 
$colname FROM $tablename [WHERE $colname = $filter]`, then the support function generates the same 
SQL and turns it into a Query node. This matches how I want to use the feature for my 
temporal_semijoin etc functions. If you give a non-NULL filter, you get a Query with a Var node, so 
we are testing something that isn't purely Const.

The SupportRequestSimplify type has some comments about supporting operators, but I don't think you 
can have a set-returning operator, so I didn't repeat those comments for this new type.

I split things up into three patch files because I couldn't get git to gracefully handle shifting a 
large block of code into an if statement. The first two patches have no changes except that 
indentation (and initializing one variable to NULL). They aren't meant to be committed separately.

Rebased to a83a944e9f.

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com