On Fri, May 10, 2002 at 11:24:40PM +0200, Peter Eisentraut wrote:
> Iavor Raytchev writes:
>
> > 3] Still - the only thing that is not clear to me is - who is going to
> > collect all patches and make one whole form them. As long as each of us
> > works on a different thing - this should not be a big problem, but still -
> > needs to be one person.
>
> As far as I'm concerned, there is no need to change anything. If someone
> has patches for pgaccess, send them to -patches and they will be applied.
> When a new release of PostgreSQL happens, a new pgaccess will be
> distributed. Simple enough.
>
> If and when patches for pgaccess appear in significant numbers and for
> some reason, which I cannot imagine, this procedure doesn't end up being
> practical, we can consider the alternatives. But before you spend a lot
> of time building a new infrastructure, let's see some code.
All very practical, execpt for one point: the people being pulled togther
for this _have_ code, with nowhere to put it: they've been developing
new features for pgaccess, on top of the stable pgsql. Tracking CVS
tip means that the current version of pgaccess there is either broken
by underlying pgsql changes (I think that is currently true with Tom's
schema work) or does not work with the current stable version og pgsql.
While it would be nice to have one pgaccess that can work with any pgsql
backend, that's not currently the case. One solution would be to work
on the release branch, but that's discouraged - bug fixes only.
Ross