On 12/16/21 11:22, Bryn Llewellyn wrote:
> Folks who develop applications for Oracle Database have had the features that the subject line of this email lists
sincethe arrival of PL/SQL in the early nineties. The advantages are self-evident to these programmers; and their lack
comesas a shocking disappointment when they start to write application code for PostgreSQL*. The absence of packages
andinner subprograms is huge. The absence of parameterizable anonymous blocks is a smaller limitation.
>
> Notice that this point is entirely separable from the endeavor of migrating an extant application. It has first and
foremostto do with how you think of designing code.
>
> I’ve heard rumors that some contributors to the PostgreSQL implementation are interested in bringing the PL/pgSQL
featuresthat I mentioned. If there is any such thinking, please let me know. I’m not a C coder but I’d be very
interestedin reader any ordinary prose that describes how these features might be exposed to the PostgreSQL application
developer.
Not following. To be exposed they have to exist and that is not the case
in the community Postgres. The relevant question would seem to be, how
do I get these features built?
> ________________________________________________________________________________
>
> * Full disclosure: I was the product manager for PL/SQL, working at Oracle HQ, from about 2000 through 2019 when I
startedwith Yugabyte, Inc. At least some people on this list have heard of YugabyteDB and know that it uses Postgres’s
SQLprocessing code “as is” (currently Version 11.2, but presently Version 13) on top of its own implementation of a
distributedstorage layer (inspired by Google Spanner).
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com