On Wed, Dec 15, 2021 at 4:19 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:
Re your paragraph #2, I already made the case for anonymous procedures. And I said that, to deserve the name, they must allow parameterization. They bring their value in a certain kind of scripting where you want to do stuff but leave no secondary traces. Plus the point about whether you even have the privilege to create objects. However, nobody here was convinced by this thinking.
I'd suggest if you want to debate the merits of having DO accept input arguments that you start a new thread for that; as it is only loosely related to the subject line for this thread. I'm not seeing any positions being given that such a capability would be undesirable. All anyone is saying is that our best, untested, guesses are that the benefit/cost ration of simply making "DO/LANGUAGE SQL" work, without any scope creep, is very low - namly because the benefit seems small regardless of the cost. I'm doubtful anyone has bothered to try and measure the cost. As for the benefit, I'm doubting the anonymous aspect of this makes much difference so an interested party can fairly easily use CREATE PROCEDURE to generate some actual performance data and at least plausibly argue that the results would carry over to "DO".
I do think that it’s risky to dismiss as valueless some feature that, for example, Oracle Database has (and has had since the dawn of time), and that PG lacks, unless the feature is intertwined with specific aspects of the other environment that have no counterpart in PG. The extreme example of this thinking is to dismiss the notion of PL/pgSQL packages and inner procedures as valueless except in that they might ease migrations from Oracle Database to PG.
IIUC at least one of the larger contributors to PostgreSQL, and some individuals, are deeply involved with the service of transitioning clients from Oracle to PostgreSQL. I personally don't worry about weighting my interpretations based upon that external factor but simply evaluate it within the scope and reality I observe within the PostgreSQL hacker community.
