> david.g.johns...@gmail.com wrote: > >> b...@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 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.
