From: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: linked list rewrite |
Date: | 2004-03-23 16:39:21 |
Message-ID: | mjqu10f34cm.fsf@cs.berkeley.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Re changing APIs or not.
I agree with Tom that an incremental change is easier. More
importantly, it is also easier to test your implementation.
Even if everybody agrees that the API should be changed, IMO a better
way would be to first use your implementation with the old API and go
through some thorough testing to make sure it is AOK. Once we are
certain (or as certain as we can be) about that, you can changeover to
the new API. This way, when bugs show up we won't be left wondering if
its because of the new API interacting with some hidden assumption at
the call-sites or if it is only the implementation.
One step at a time seems safer to me.
I would think a new CVS branch would be the right way to merge your
stuff especially if you are going with the API change route. That way
you won't have to lock the tip and can incrementally work with a
broken branch until it is fine (and keep re-merging).
Which brings me to another question .. has anybody considered using
subversion instead of CVS ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-23 16:47:34 | Re: linked list rewrite |
Previous Message | Steve Moyle | 2004-03-23 16:08:17 | Logging 'rows returned' |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-23 16:47:34 | Re: linked list rewrite |
Previous Message | Tom Lane | 2004-03-23 16:22:45 | Re: dollar quoting and pg_dump |