On Fri, 16 Jan 2004, Jeff Bowden wrote:
> Tom Lane wrote:
>
> >Jeff Bowden <jlb@houseofdistraction.com> writes:
> >
> >
> >>Still, the main problem I, and I suspect others, would like to solve is
> >>installation/configuration. For my app I don't want the user to have to
> >>understand anything about how keeping data in a shared
> >>system-administered database is different from keeping data in local
> >>files. Everything should "just work".
> >>
> >>
> >
> >Sure, but most of the existing packagings of PG already try to make this
> >automatic (at least Lamar's RPMs and Oliver's Debian package do). No
> >doubt further work could be invested to make it even smoother, but that
> >doesn't mean we need a client-started database.
> >
>
> So maybe this is a packaging issue. On Debian when I install postgres
> it is necessary to do root shit in order to enable non-priveledged users
> to create and destroy databases. My understanding has alwasy been that
> these operations are restricted because it can allow users to
> accidentally or intentionally interefere with each other's use of the
> server. If there is some way for this to be set up sanely by default to
> allow users to successfully use createdb and dropdb on only their own
> data, then I will file a wishlist bug against the Debian packages to add
> this. Or is this all a pipe dream?
I don't see what the problem is. PostgreSQL is perfectly able to be installed
and run as any old user. Even if one is distributing via a package system, such
as RPM perhaps, which has problems installing as non-root user if one sees the
package already installed then there's no need to try to install it
again. Even with the package installations there's bugger all stopping any old
user doing an initdb -D myownplace.
The standard postgres user on a system is only special in that it is generally
the user the postmaster is run as. If you have other non-priviledged users and
there's no need for them to share a cluster why try to make them?
--
Nigel Andrews
