Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes

From: dg(at)illustra(dot)com (David Gould)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: phil(at)river-bank(dot)demon(dot)co(dot)uk, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Date: 1998-05-22 07:00:02
Message-ID: 9805220700.AA11579@hawk.illustra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

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(at)illustra(dot)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(at)tybalt(dot)caltech(dot)edu)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Gould 1998-05-22 07:33:16 Current sources?
Previous Message Stupor Genius 1998-05-22 05:27:41 RE: [HACKERS] Bug in postgresql-6.3.2

Browse pgsql-interfaces by date

  From Date Subject
Next Message Peter Mount 1998-05-22 07:53:25 RE: [INTERFACES] Problem building the JDBC driver
Previous Message Bruce Momjian 1998-05-22 04:36:32 Re: [HACKERS] Time to fix libpgtcl for async NOTIFY