> 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
No comments:
Post a Comment