Josh Berkus wrote:
> On 08/05/2015 10:26 AM, Bruce Momjian wrote:
> > I don't care what we do, but I do think we should be consistent.
> > Frankly I am unclear why I am even having to make this point, as cases
> > where we have chosen expediency over consistency have served us badly in
> > the past.
>
> Saying "it's stupid to be consistent with a bad old rule", and making a
> new rule is not "expediency".
So I discussed this with Bruce on IM a bit. I think there are basically
four ways we could go about this:
1. Add the functions as a builtins. This is what the current patch does. Simon seems to prefer this, because he
wantsthe function to be always available in production; but I don't like this option because adding functions as
builtins makes it impossible to move later to extensions. Bruce doesn't like this option either.
2. Add the functions to contrib, keep them there for the foreesable future. Simon is against this option, because the
functionswill be unavailable when needed in production. I am of the same position. Bruce opines this option is
acceptable.
3. a) Add the function to some extension in contrib now, by using a slightly modified version of the current patch,
and b) Apply some later patch to move said extension to src/extension.
4. a) Patch some extension(s) to move it to src/extension, b) Apply a version of this patch that adds the new
functionsto said extension
Essentially 3 and 4 are the same thing except the order is reversed;
they both result in the functions being shipped in some "core extension"
(a concept we do not have today). Bruce says either of these is fine
with him. I am fine with either of them also. As long as we do 3b
during 9.6 timeframe, the outcome of either 3 and 4 seems to be
acceptable for Simon also.
Robert seems to be saying that he doesn't care about moving extensions
to core at all.
What do others think?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
