> p...@bowt.ie wrote: > >> b...@yugabyte.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.steh...@gmail.com <mailto:pavel.steh...@gmail.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.
