My message, sent six weeks ago, started a thread. I believe that Pavel’s message, sent about a week later, is the most recent. In this turn, I’ve tried to copy everybody who contributed to the thread. In one of the turns, I promised a proper write-up of my case for PL/pgSQL packages. It took me some time because of the usual reasons (the Holiday period and ordinary work). It’s done now—attached as case-for-plpgsql-packages.zip. I decided to exclude the “parameterizable anonymous blocks” part of what I wrote to start this thread from my write-up. It’s an entirely separable notion. I allowed myself to change the “Subject” of this reply to reflect this.. The .zip contains these files:
I’d be delighted to hear suggestions for a better runnable PL/pgSQL implementation—and happy to revise my code and write-up to use this. I’d also welcome general feedback (ordinarily in email, of course) and I’d be happy to revise my work and make a new .zip. Finally, here are snippets from some of the responses. I hope that my essay, taken in its entirety, addresses all of these questions. pg@xxxxxxx wrote: Why are those things huge? It’s not self-evident to me. I can only speak for myself, but throwing around terms like “shocking disappointment” is never going to convince me of anything. You can make similar statements about many other things. pavel.stehule@xxxxxxxxx wrote: There are a lot of successful migrations from Oracle to Postgres that shows so that the absence of mentioned features isn’t too huge. Postgres is just not compatible with Oracle. The compatibility with Oracle is not possible without monstrous increasing size and complexity, and this is a benefit just for a small part of users. A lot of packages and concepts in Oracle are obsolete, or maybe not too well designed (from today’s perspective). After my experience I think there are a lot of things that are possible in stored procedures, but I am sure it is not good to do it, and I don’t think we need to promote these patterns in Postgres. gogala.mladen@xxxxxxxxx wrote: ORAFCE uses schemas as the package names. However, one very practical thing is missing: session variables. Yes, you can emulate those with ON COMMIT PRESERVE ROWS temporary tables, but that’s a rather ugly hack. On the other hand, packages can easily be emulated by using Python. Having packages would make PLPg/SQL programming much prettier. It would be much prettier to group related routines into a package than to have them laying around without anything indicating that the routines are related. On the plus side, packages would make it much easier to migrate from Oracle to Postgres. laurenz.albe@xxxxxxxxxxx wote: I am not trying to belittle this, but when you are used to system A and start working with system B you always miss some features of A, until you get to know B better and figure out how to do things there. bryn@xxxxxxxxxxxx wrote: I firmly believe that the intrinsic value of all of this has nothing to do with Oracle Database, with migrating from it to PG, or with Ada. It’s just that Oracle’s PL/SQL has a working implementation. And many people find it easier to think when they can experiment with something concrete rather than trying to hold, and run, a pretty big abstract model entirely in their head. pg@xxxxxxx wrote: 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? |
<<attachment: case-for-plpgsql-packages.zip>>
