Re: Why can't I have a "language sql" anonymous block?

On Wed, Dec 15, 2021 at 4:19 PM Bryn Llewellyn <bryn(at)yugabyte(dot)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.

David J.