>> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that >> > achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have >> > the inlining logic look at the cost of the wrapper and the cost of >> > parameters, and if the cost of the wrapper "greatly exceeded" the cost of >> > the parameters, then inline. So the PostGIS project would just set the >> > cost of our wrappers very high, and we'd get the behaviour we want, while >> > other users who want to use wrappers to force caching of calculations >> > would have zero coded wrapper functions. Pros: Solves the problem and >> > easy to implement, I'm happy to contribute. Cons: it's so clearly a hack >> > involving hidden (from users) magic. >> > ... >> > So my question to hackers is: which is less worse, #1 or #2, to implement >> > and submit to commitfest, in case #3 does not materialize in time for >> > PgSQL 12? >> >> I've been working with Paul to create and test a patch (attached) that >> addresses Solution #2. This patch essentially modifies the inlining >> logic to compare the cost of the function with the total cost of the >> parameters. The goal as stated above, is that for these kinds of >> functions, they would be assigned relatively high cost to trigger the >> inlining case. > > > I've tested this patch for both the internal types case and for the PostGIS > functions case, and in both cases it provides a way to get around the > undesirable inlining behaviour for our case without impacting people for whom > the behaviour has been desirable in the past. > > Is this already in the commitfest?
Yes. https://commitfest.postgresql.org/21/1965/ -Adam
