On Thu, 1 Aug 2002, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Until we have folks who are excited enough about it to plan it out and
> > do the work, piecemeal rejection of components is not leading to a more
> > solid product.
>
> I'm lukewarm about whether to actually do the split or not ... but for
> sure I agree with Thomas' point here. We need a plan and careful
> implementation, or a split-up will just make life worse.
>
> Stuff that is in the tree tends to get maintained in passing. For
> example, I've got some changes to contrib/dblink/ in my in-progress
> version of Chris' DROP COLUMN patch, because a grep for references
> to rel->rd_att turned it up. If dblink weren't in our CVS it'd have
> been broken by DROP COLUMN, and who knows whether we'd catch that
> during beta? I realize that Marc wasn't proposing splitting off any
> server-side code, but I still want to tread carefully about breaking
> up the codebase.
Okay, well, the way I'm working it through right now, I'm doing it in such
a way that unless you go mucking in the repository directly, it will be
transparent to the coders, as well as to the distribution as a whole ...
In fact, based on a comment that Thomas made in another email, I'll even
fix up the whole 'cvs checkout pgsql' thing so that that goes back to its
previous incarnation of pulling everything, instead of needing to do
pgsql-all ...
So, from the 'client side', y'all will still see "everything as one big
package", while from the 'server side', I'll have the seperate modules
taht can be packaged independently ...
Next, unless Peter knows how to do it already, I've gotta learn to make
configure more intelligent, so that for all intents, the "pieces" look
like one package when building, not just when coding ...
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
