From my POV there are two "costs" here:
1) The speed degradation by supporting multiple versions of postgres.
I tend not to be too concerned by speed, and more concerned with ease of
use. If speed really becomes an issue I can go into the code and remove
the offending inefficiency caused by supporting multiple versions.
2) The barrier to entry by new jdbc, and postgres users trying to use
postgres, and jdbc for the first time. If it doesn't work out of the
box, then they will leave.
I have a bias towards making it easier for people to use the software.
However given the speed of server development. How far "back" are we
going to support ? An argument can be made that since the software is
free then there really is no reason not to upgrade. The biggest reason
for me not to upgrade my server is reliability. What I have now works! I
am hesitant to upgrade the server on a server which needs to run 24/7.
That being said I am more likely to upgrade the jdbc driver, since:
1) it is really easy to back out the upgrade.
2) I have some ability to debug the jdbc driver and figure out what is
going wrong. My ability to debug the postgres server is significantly
less (approaching 0).
So along with making it easier for new people to get the code up and
running with a minimum of effort. I would like to take advantage of new
jdbc features on older servers.
My 2 cents worth
Dave
On Mon, 2001-09-03 at 19:46, Tom Lane wrote:
> Barry Lind <barry@xythos.com> writes:
> > The multiple statements in one call is there for performance reasons.
> > Please don't remove it entirely since it works fine in 7.1 and 7.2.
> > Instead your fix should be conditional based on server version:
>
> Given that someone else is proposing a patch that will break backward
> compatibility to 7.0 servers anyway, I'm unconvinced that we need this
> at all. Perhaps a discussion about the costs and benefits of backwards
> compatibility in the JDBC driver is needed --- what tradeoffs do people
> want to make?
>
> regards, tom lane
>
>
