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

Re: shared library strangeness?

From: Bill Studenmund <wrstuden(at)zembu(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared library strangeness?
Date: 2001-07-02 16:29:23
Message-ID: Pine.NEB.4.21.0107020916240.370-100000@candlekeep.home-net.internetconnect.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 22 May 2001, Bruce Momjian wrote:

> I am always confused when to bump the minor and when the major.  I also
> was not sure how significant the change would be for apps.  We added
> const, and I changed the return type of one function from short to int. 
> Seems like ConnectionBad was also changed.

Sorry for the delay.

You need to bump the minor whenever you add to the library. You need to
bump the major whenever you delete from the library or change(*) the
interface to a function. i.e. if a program links against the library, as
long as the routine names it linked against behave as it expected at
compile time, you don't need to bump the major.

(*) NetBSD (and I think other OSs too) use a gcc-ism, RENAME, to be able
to change the interface seen by new programs w/o changing the minor
number. What you do is prototype the function as you want it now, and have
a __RENAME(new_name) at the end of the prototype. When you build the
library, you have a routine having the old footprint and old name, and a
new routine with the new footprint and named new_name. Old programs look
for the old name, and get what they expect. New programs look for the new
name, and also get what they expect.

I'm not sure if Postgres needs to go to that much trouble.

Take care,

Bill


In response to

Responses

pgsql-hackers by date

Next:From: Phillip F JansenDate: 2001-07-02 16:36:04
Subject: tab
Previous:From: Thomas SwanDate: 2001-07-02 16:13:41
Subject: Re: New data type: uniqueidentifier

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