Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
Bruce Momjian wrote: 
> > 
> > Tom Lane wrote:
> > > 
> > > 
> > > 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

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.


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


pgsql-hackers by date

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

pgsql-interfaces by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group