Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes - Mailing list pgsql-hackers
From | dg@illustra.com (David Gould) |
---|---|
Subject | Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes |
Date | |
Msg-id | 9805220700.AA11579@hawk.illustra.com Whole thread Raw |
In response to | Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes |
List | pgsql-hackers |
Bruce Momjian wrote: > > > > Tom Lane wrote: > > > > > > PROTOCOL CHANGES: > > > > > > We should change the protocol version number to 2.0. > > > It would be possible for the backend to continue to support 1.0 clients, > > > if you think it's worth the trouble to do so. > > > > Or 1.1? The changes don't seem too traumatic. Either way, maintaining > > support for 1.0 is important as not all of us use libpq and we need time > > to catch up. Also we don't want to put barriers in the way of companies > > like Openlink who seem willing to provide support for PostgreSQL in > > commercial products. > > Yes, but there will be a month for people to get their third-part stuff > changed, and the changes are pretty straight-forward. Having support > for both in the backend/frontend is going to make that code more > difficult. > > If it was only a small change, we could keep it compatable, but it seems > it would be best to just announce it early on. People can start testing > their new drivers long before the beta period begins. > > Also, we are making this change well in advance of the beta, so I hope > they would have enough time to make the transition. I know this is old old discussion, so "shut up, we're done with it" is a fine answer... But, I think maintaining compatibility with 1.0 is important. If we expect people to really use this software to build real applications, then we cannot expect them to be interested in revising or even recompiling their applications. For example a web development consulting house. They build shopping cart or other database using web sites for their clients. They do not want to have to go to each of their customers (say hundreds of sites) and recompile everything just to take advantage of a new server that happens to fix some bugs they needed fixed. They also don't want to reload the databases or otherwise get involved in upgrade issues. And, their clients don't want to pay for this either. Database customers at least in the commercial world can be incredibly conservative. It is not at all uncommon to have large sites running DBMS engines that are three major releases (ie, well over three years) old. Once they get an app working, they really don't want anything to change. -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 "Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right." --David Palmer (palmer@tybalt.caltech.edu)
pgsql-hackers by date: