> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page > Sent: 21 October 2006 21:20 > To: PgAdmin Hackers > Subject: [pgadmin-hackers] FW: [HACKERS] adminpack and pg_catalog > > > [Ooops, forgot to CC the list]
And then got the wrong one. D'oh!! > ------ Forwarded Message > From: Dave Page <dpage@vale-housing.co.uk> > Date: Sat, 21 Oct 2006 21:18:42 +0100 > To: Peter Eisentraut <[EMAIL PROTECTED]> > Conversation: [HACKERS] adminpack and pg_catalog > Subject: Re: [HACKERS] adminpack and pg_catalog > > > > > On 21/10/06 12:13, "Peter Eisentraut" <[EMAIL PROTECTED]> 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 > > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match