Horton

Re: New "single-call SRF" APIs are very confusingly named

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Melanie Plageman <melanieplageman@gmail.com>, pgsql-hackers@postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Date: 2022-10-18T01:59:49Z
Lists: pgsql-hackers 
On Mon, Oct 17, 2022 at 10:13:33AM +0900, Michael Paquier wrote:
> That's just assign_record_type_typmod(), which would make sure to fill
> the cache for a RECORD tupdesc.  How about "fill the cache with the
> information of the tuple descriptor type, for a transient RECORD
> datatype"?  If you have a better, somewhat less confusing, idea, I am
> open to suggestions.

At the end, I was unhappy with this formulation, so I have just
mentioned what the top of BlessTupleDesc() tells, with the name of
the function used on the tuple descriptor when the flag is activated
by the init call.

The compatibility functions have been removed from HEAD, by the way.
--
Michael

Commits

  1. Remove compatibility declarations for InitMaterializedSRF()

  2. Rename SetSingleFuncCall() to InitMaterializedSRF()

  3. Create routine able to set single-call SRFs for Materialize mode