Re: pg_background (and more parallelism infrastructure patches)

> What about moving it the opposite direction, from contrib all the way
> into core?  The main advantage of that in my book is that it might
> make it easier to reduce the code duplication between pg_background
> and exec_simple_query; the main disadvantage is that it reduces the
> super-user's control, because now the functionality is always
> available instead of being something that the super-user can choose to
> install, or not.
>
> But these are all judgement calls, of course.

I lean toward a push into core because:

1. "I expect that eventually all of this stuff will be
used in core - for parallelism."

2. Contrib is already bloated out. (which is a whole other discussion)

3. I am not sure I buy into the super-user argument. Just because the 
functionality is there, doesn't mean it has to be used.

4. "The main advantage of that in my book is that it might
make it easier to reduce the code duplication between pg_background
and exec_simple_query;"

JD



-- 
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should             not be surprised when they come back as
Romans."