Michael Gould <mgould(at)intermodalsoftwaresolutions(dot)net> wrote:
> 1. The ability to encrypt stored procedures and triggers. I know
> that PostGres doesn't have this feature but is there a way to
> protect stored procedure and trigger source yet allow it to be
> executed by any user and how would it be done.
You could code them in a compiled language (like C) and the user would
only see a reference to the library file.
> 2. We do not want the table schema to be accessed by outside
> applications. Since our application is so normalized, accessing
> these tables directly will not make a lot of sense to our users so
> we create views that are more user friendly for doing reports,
> accessing the data via Excel, etc. How would we do this in
> Postgres.
You could put the tables in a separate schema, which you would not put
on the default search path. The views could refer to the tables with
the schema qualifier. This would not hide the tables from the users,
per se, but would cause them not to show on casual display, or allow
them to be accessed without explicitly specifying the schema.
> 3. We use active directory to validate a user's login. We have
> "rules" and functionality security built in as stored procedures.
> How would we do this under Postgres. We do this with a
> configuration variable during the login process stored process. If
> the company uses active directory we use it to validate the user, if
> not then we present a user login and require that a login be
> manually entered. For those companies that use active directory we
> try to have our application validate the AD so that the user isn't
> required to multiple applications.
I don't know anything about that. Perhaps someone else will jump in
with advice.
-Kevin