david.g.johnston@xxxxxxxxx wrote:
bryn@xxxxxxxxxxxx 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 ratio of simply making “DO/LANGUAGE SQL” work, without any scope creep, is very low—namely 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”.
bryn continued:
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.
[If I understand correctly] 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.
Thanks, David. Yes, mea culpa. I muddied the discussion so that the “Subject” line no longer reflects the content.
W.r.t. my initial question (“Why can’t I have a ‘language sql’ anonymous block?”), I’m going to say “case closed”. The various answers that I’ve read have shown me that “language sql” can bring only a possible performance benefit and can do this only for a function ‘cos only a function can have its body inlined into the SQL statement that invokes it.
I’ll start a new thread on parameters for anonymous blocks, inner subprograms and packages for PL/pgSQL stored functions and procedures. |
