> How can you request a vote of such a limited audience? *Adding*
> functionality is easy ... removing functionality with at least a release
> for-warning is easy ... removing a feature without any forewarning is akin
> to cutting our own throats ...
Yea, but it was such an ugly feature and I honestly thought no one was
using it. In fact, you aren't even using it in the indended way of
sharing /etc/passwd. You are using it to implement a different
capability that I never even imagined. :-)
>
> > OK, here is the request for vote. Do we want:
> >
> > 1) the old secondary passwords re-added
> > 2) the new prefixing of the database name to the username when enabled
> > 3) do nothing
>
> If 2 can be done in such a way to be transparent, as well as to allow a
> database owner to be able to create users for his/her database, then I
> think it would be great ... and would far exceed what we have now ...
>
> If you can't do 2 as a complete solution, which, IMHO, includes a db owner
> being able to create db.users for his own database, then my vote is for 1
> ... if 2 can be done completely, then I vote for 2, as it would definitely
> be much more useful ...
Well, as it currently stands in the patch, a db owner can create any
user they want, including users for just their dbs. However, remember
that Once someone can create a user, they can create a superuser, so
security for those folks is impossible. The patch does not prevent them
from creating user for other databases, if that is what you wanted, but
did your previous solution allow this?
>
> Hrmmm ... I was just thinking of another scenario where such a feature
> would be great ... educational. The ability to setup a database server,
> but to give a professor a database for a course that he could create
> 'accounts' for each of the students ...
Yep, with no conflicting names.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
