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>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-10-17T01:06:36Z
Lists: pgsql-hackers 
On Sun, Oct 16, 2022 at 03:04:43PM -0700, Andres Freund wrote:
> Yes - it'd introduce an ABI break, i.e. an already compiled extension
> referencing SetSingleFuncCall() wouldn't fail to load into an upgraded sever,
> due to the reference to the SetSingleFuncCall, which wouldn't exist anymore.

Note that this layer should just be removed on HEAD.  Once an
extension catches up with the new name, they would not even need to
play with PG_VERSION_NUM even for a new version compiled with
REL_15_STABLE.
--
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