Re: Do we really want to migrate plproxy and citext into PG core distribution?

On 7/23/08, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
> > Do you want Tom to
> > a) spend a month improving the optimizer
> > b) get him to review already working code so we can package things
>
> Actually, if the alternative is having the pieces outside of core where
> Tom never sees them, I'd vote for (b), as the optimizer already kicks ass
> but having Tom review other code is pretty invaluable.
>
> Code outside of core, is, in reality, less reviewed, less likely to work
> well with recent PG versions, and more likely to cause problems. It's also
> less likely to be found by people, less likely to be used by people, and
> less likely to be included by distros. Not to say that everything should get
> shoved into core, of course, but there are strong arguments for both sides.

Agreed.

But PL/Proxy has one additional problem.

First, it's a small & simple clustering solution that plays very well
on Postgres strengths - transparent plan cache in functions, transactional
DDL, etc. It allows significantly higher uptime and query-per-sec than
any "plain sql" solution.

But it has serious weakness - it is not "transparent", user needs to change
it's coding style to function-based one. (This is related to the
small-and-simple property.)

So, for it to be useful, the users need to be aware of it as early in
development as possible. And the idea to turn pgfoundry into CPAN
is pointless. An user may willing to throw random modules to his
random perl script, but not to his whole db architecture. So it needs
to be either in main distro or nearby it.

OTOH, the most serious argument against PL/Proxy merge is that when we
do remote tables/views based on SQL-MED, it's quite natural to extend
that on functions, thus making plproxy redundant.

OTOH^2, there has not been any serious thinking on that direction AFAICS,
except how "dbi-link can push down WHERE clause", This suggests it wont
appear before 2011... Not that its a argument for merge, but maybe
pushing it to an "all-presentable-extensions" package and having proper
review done would be a good idea.

--
marko