Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

From: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Subject: Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL
Date: 2021-12-17 23:53:11
Message-ID: 4C7E6E82-ACA1-4CCD-BFAC-89A11479C8C7@yugabyte.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> pg(at)bowt(dot)ie wrote:
>
>> bryn(at)yugabyte(dot)com wrote:
>>
>> Modular design recommends exposing functionality through a purpose oriented interface and hiding all implementation details from the API’s user. A package achieves this with declarative syntax via the spec/body separation. The body encapsulates as many (top-level) subprograms as you want. Each of these is visible to all of its peers. But none is visible outside of the package unless the spec declares that it should be. This is a simple opt-in scheme.
>
> I still don’t get it. It sounds like you’re mostly talking about encapsulation, or Information hiding, for stored procedures. I can certainly see how plpgsql doesn’t do those things very well, but it still seems like there might be a lot of nuance that isn’t getting across. The list of specific features that seem to be missing are not unreasonable, individually, and yet it feels like I cannot see some bigger picture that's apparent to you.
>
> Maybe you should explain your position by way of a motivating example, involving a real world use case. Something that makes the issues concrete. Are these items compelling because of how they allow an organization to deploy a program in a production environment, complete with version control? Does it have something to do with decoupling the mutable business data stored in tables from the programs contained/run in the same database?

I can certainly make up an example. I’ll do this over the weekend. However, I fear that it will be time wasted because at least some of the addressees here who’ve expressed strong opposition to the notion of PL/pgSQL packages must understand very well what they’re objecting to. For example, pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com> with his “schema variables, LET command” work.

Anyway… I’ll give it my best shot. I’ll try to address your specific questions in my follow-up reply. Hang on for a couple of days, please.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Shubham Mittal 2021-12-19 11:50:21 PGBouncer logs explanation required
Previous Message Peter Geoghegan 2021-12-17 23:05:12 Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL