So far that's all "that'd be nice, but isn't a technical barrier" stuff.
Package variables for example. When _do_ you _need_ them? For what? (I'm aware of some uses but "when you need them" helps us not at all).
Well my answer would be, "because we want Oracle people to have an easy time migrating". I know that isn't the -hackers answer but clearly there is a demand for them. I would note that EDB Advanced server supports them, exactly because there is a demand for them.
EDB try to emulate Oracle - so some special features are necessary there - although are redundant to existing PostgreSQL features - packages, collections, ..
Again, I am not making the technical argument here. I don't have the time to research it. I am making a usability argument for a potentially huge portion of database users to allow PostgreSQL to be more attractive to them, argument.
I also received this today:
""" Well, packages make programming much easier. Not only do you keep related procedures together, you can also have private package variables and the package initialization. Also, packages are units of security, so you can grant permissions on the package to the entire group of users and if you later modify the package and add a function, you don't need to grant it separately. """
This is possible with our schemas too. I use schemas for package emulation for Orafce 10 years, and it is working well.
The main problem is in different languages - our "database" <> Oracle "database", our "schema" <> Oracle "schema"
People doesn't want packages - they want Oracle without any fee
Sincerely,
JD
-- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. Unless otherwise stated, opinions are my own.