Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL
Date
Msg-id DB6BA005-5622-4135-AB4A-015E955622E6@yugabyte.com
Whole thread Raw
In response to Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
adrian.klaver@aklaver.com wrote:


Folks who develop applications for Oracle Database have had the features that the subject line of this email lists since the arrival of PL/SQL in the early nineties. The advantages are self-evident to these programmers; and their lack comes as a shocking disappointment when they start to write application code for PostgreSQL*. The absence of packages and inner 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 foremost to 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 features that I mentioned. If there is any such thinking, please let me know. I’m not a C coder but I’d be very interested in 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?

Bryn continued:

* Full disclosure: I was the product manager for PL/SQL, working at Oracle HQ, from about 2000 through 2019 when I started with Yugabyte, Inc. At least some people on this list have heard of YugabyteDB and know that it uses Postgres’s SQL processing code “as is” (currently Version 11.2, but presently Version 13) on top of its own implementation of a distributed storage layer (inspired by Google Spanner).

Oops. I did a typo. I’d meant to write “I’d be very interested in *reading* any ordinary prose…”

I can’t parse your “To be exposed they have to exist and that is not the case…” Do you mean that the rumor that I heard is wrong and that nobody has said to the Postgres community that they’ve embarked on, or at least are interested in, implementing what I’m asking about?

I had assumed that the answer to “How do I get these features built?” was “Write a C implementation and submit it for consideration”. But I can’t do that. The obvious Google searches like “Submit enhancement request for PostgreSQL” turn up only informal emails to lists like this. Is there a better answer?

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: How to ensure column names are double quoted while using execute format when building a stored procedure?
Next
From: Tom Lane
Date:
Subject: Re: SELECT DISTINCT scans the table?