On Sep 25, 2008, at 3:13 AM, Asko Oja wrote:
but why would you put part of your business logic into some configuration tables while you could keep it in your own functions
Because as bad as my Not Invented Here syndrome might be at times, I know that I would not be able to alone build as elegant of a system as the community could together, which would be more adaptable and generic. Things tend not to make it into PostgreSQL releases until they are very solid.
Then instead of worrying about whether or not my function code is good, I can rely on the PostgreSQL-provided foundation, using things in a standard, supported way. If there is a bug, it's found, fixed, and the whole community benefits. Many people could benefit from SAR support, so why make them all spend time reimplementing thigs?
There is a much, much more important reason for this though, which is that I can only extend security functionality by adding additional restrictions within my function call. The SAR stuff in Oracle is superior to this because it affects *all use of the database*, not just function calls. I don't put much value in security through obscurity - sorry.
To an extent we *can* simulate row-level and column-level security through the use of very restricted data tables and more generally- available or specific-purpose views, but we cannot make PostgreSQL call a custom function to determine from it's output whether or not it should allow a particular action.
I see it as a strong side of PostgreSQL that we have not bloated our code with all this fancy micromanagement that seems too complex to be useful anyway considering that quality of Oracle database management tools :)
Lack of bloat is a strong point. Bloat is more the result of putting things in without enough forethought, and then needing to maintain compatibility with old stuff even after you add better - the maintenance of the old code interfering with the time/quality put into the new, etc. It's also a question of how well they are implemented. If 0.1% of the user base will use a feature, it's probably not worth adding. If 10% will use it, but it's implementation requires added overhead for the 90% of others who don't - that's bloat. If 10% will use it, and it doesn't cost anything to those who don't, it's worth doing.
I would like to clarify that I'm not saying anything like "PostgreSQL needs / should have SAR support" in this thread, although I would personally find them handy. I just wanted to clarify that what "roles" means to an Oracle DBA is a lot different from what it means to a PostgreSQL DBA.
Cheers, -- Casey Allen Shobe Database Architect, The Berkeley Electronic Press -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
