Dave Page wrote:
> > Right now you have got plenty of time to get it in shape for inclusion in
> > core, so we might not even have to take the detour through a contrib module.
>
> As it stands it was previously rejected for inclusion in -core in it's
> current form. The main objector was Tom, but as it was him that
> encouraged me to change the licencing for inclusion as a contrib module
> I assume he doesn't object to that.
>
> I have submitted a conference discussion proposal to talk about ways
> of implementing the remote configuration that we want which was the
> main thing I think Tom objected to originally, but that's some time
> away and would likely result in a significantly more complex solution
> that may or may not get done for 8.2. In addition, there are one or
> two helper functions in there that were previously rejected more on
> the 'no use to end user' basis iirc (see pg_logdir_ls) which may never
> end up in -core without reconsideration of the need. It would be good
> (for us at least) to get it in as a contrib, even if we do manage to
> replace it, or some of it, by release.
+1 for /contrib
I think the issue was that adding these fuctions adds a potential
security opening, so we didn't want it in core by default, but /contrib
seems logical because anyone who needs it can just add it.
This is similar to the fact we don't include plpgsql by default in
databases, for the same reason, but we have the ability to use
createlang to add it. Adding these functions to contrib gives us the
same control.
-- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
