If we are talking about enhancement requests, I would propose we create a
role that can be granted/revoked that enables a user to see dictionary
objects like source code. Secondly, users should be able to see their own
code they write but not others unless they have been granted this dictionary
Revoking pg_proc isn't good for users that shouldn't see other's code but
still need to be able to see their own code.
> -----Original Message-----
> From: Kris Jurka [mailto:books(at)ejurka(dot)com]
> Sent: Monday, December 17, 2007 10:51 PM
> To: Merlin Moncure
> Cc: Roberts, Jon; Jonah H. Harris; Bill Moran; Joshua D. Drake; pgsql-
> Subject: Re: [PERFORM] viewing source code
> On Mon, 17 Dec 2007, Merlin Moncure wrote:
> > the table is pg_proc. you have to revoke select rights from public
> > and the user of interest. be aware this will make it very difficult
> > for that user to do certain things in psql and (especially) pgadmin.
> > it works.
> > a better solution to this problem is to make a language wrapper for
> > pl/pgsql that encrypts the source on disk. afaik, no one is working on
> > th is. it would secure the code from remote users but not necessarily
> > from people logged in to the server. the pg_proc hack works ok
> > though.
> Another enhancement that would improve this situation would be to
> implement per column permissions as the sql spec has, so that you could
> revoke select on just the prosrc column and allow clients to retrieve the
> metadata they need.
> Kris Jurka
pgsql-performance by date
|Next:||From: Alvaro Herrera||Date: 2007-12-18 18:26:49|
|Subject: Re: viewing source code|
|Previous:||From: Heikki Linnakangas||Date: 2007-12-18 09:23:10|
|Subject: Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not