FW: [HACKERS] adminpack and pg_catalog

[Ooops, forgot to CC the list]

------ Forwarded Message
From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Date: Sat, 21 Oct 2006 21:18:42 +0100
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Conversation: [HACKERS] adminpack and pg_catalog
Subject: Re: [HACKERS] adminpack and pg_catalog

On 21/10/06 12:13, "Peter Eisentraut" <peter_e(at)gmx(dot)net> wrote:

> Dave Page wrote:
>> Well as adminpack is specifcally and primarily written to support
>> pgAdmin, deliberately breaking it for current and older releases of
>> pgAdmin does seem like a *really* dopey thing to do. So yeah, I would
>> prefer it was removed than broken, even if to the annoyance of the
>> packagers and users that bugged us to get it included in the first
>> place.
>
> I understand that randomly breaking it is not the way to go.
>
> But how it this going to continue? A new pgAdmin release might
> conceivably want to add or change the adminpack.

I think that's unlikely, but yes, it's possible.

> Will that have to
> wait for a new server release.

PgAdmin is released on virtually the same timetable as PostgreSQL - it has
to be to sync up the docs and levels of support in the Windows pgInstaller
distro, so that's not an issue.

> Given the understanding that adminpack
> is specifically for pgAdmin support, I don't see any advantage in
> shipping it with the server, the buggers notwithstanding.

The message we've consistently had from both packagers of PostgreSQL and
users is that the module should be included in /contrib and not pgAdmin,
precisely because it is a server side module, and many people don't
necessarily want to install pgAdmin, or bits of it separately on their
servers. We here the same argument about pgAgent from time to time, but that
isn't really a candidate for inclusion in /contrib due to it's current
reliance on wxWidgets - otherwise I'd be arguing to get that included as
well.

Regards, Dave

------ End of Forwarded Message