> On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
>> It isn't just "an" environment variable, it is a number of variables and
>> a
>> mechanism. Besides, "profile," from an admin's perspective, is for
>> managing users, not databases.
>
> Sure, you need to control the user, group, placement of logfile and
> several other things.
>
> <snip>
>
>> I think Chris said it right, I don't want to make policy, I would to
>> provide functionality. I know my service environment is not unique, and
>> so
>> what if it is only about 10% (or less) of the PostgreSQL users? There is
>> a
>> need for this, and it is a valuable "enterprise" level feature. DB
>> admins
>> will recognize and use this feature. It makes a lot of sense if you
>> stand
>> back and think of the admin process instead of the core database.
>
> How is any of this different from the way Debian handles multiple
> simultaneous clusters? Is there any particular reason you couldn't use
> it or a variation thereof (other than that it enforces a particular
> policy, namely debian's)? The source is available [1] and a quick
> demonstration was posted [2].
Well, I'm sure that one "could" use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide the
mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
admin manual?
We are talking about a feature, like pg_service.conf, now that people
notice it, we are saying "WOW, this is the API we should push." This is a
functionality, IMHO, must be the responsibility of PostgreSQL.
>
> In any case, nothing stops anyone from starting a project on
> pgfoundary. Nothing convinces people quite like working code. Since
> -core seems uninterested, I think this would be the best way to go.
Argg, the pgfoundary is sort of the "free speech zones" that the U.S. sets
up out of view of the president and the press. Yea, its there, and if you
go out of your way, you can find it. Think of Arthur Dent's "The plans
were on display!"