Bruce wrote:
> > And I don't know if ALL the places where IsSystemRelationName()
> > is used are happy with things that in fact aren't really
> > hardwired system catalogs.
>
> Can I suggest pgview_ then? Another problem is that a \d on an empty
> database, \d is going to show this view, isn't it. Kind of strange to
> me.
>
> I have a solution. Create the view in initdb as pguser_no_pwd, then
> after that execute an update statement on pg_class:
>
> update pg_class
> set relname = 'pg_user_no_pwd'
> where relname = 'pguser_no_pwd';
>
> We are using Jan's cache fix already. I just tried it and it works.
> And it means it doesn't show up in \d, and a user can't accidentally
> delete it. Sounds like a real winner.
Sounds really good - if we can be sure that the pg_ prefix of
a view never collides with the IsSystemRelationName() tests
somewhere (there are many). You got me. Let's leave all
postgres specific stuff in pg_*.
But as it was done in most UN*X's, could we rename the
pg_user containing the password into pg_shadow and then
create a view pg_user that just stars out the password field?
This way no existing application code (not even the JDBC
etc.) needs any changes, except for the createuser etc.
tools that always get installed with the new release.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
