* Michael Meskes <meskes@postgresql.org> [000918 05:03] wrote:
> If I change some stuff in a library that forces the user to recompile all
> programs because it's not binary compatible I have to change the major
> number right? But just changing the order in an enum datatype does not
> exactly look like such a big change. But the only way to avoid this problem
> is adding the new entries at the end of the enum. Or do I miss something
> obvious here?

If you re-order an exported emum you are going to complete break binary
compatibility, either bump the major or add the entries at the end.

However there's another problem even if you add at the end, namely
that if previously the 'default' doesn't describe the new values
then you also break compatibility, for instance:

Chapter 17. libpq - C Library

..

    At any time during connection, the status of the connection
    may be checked, by calling PQstatus. If this is CONNECTION_BAD,
    then the connection procedure has failed; if this is CONNECTION_OK,
    then the connection is ready. Either of these states should be
    equally detectable from the return value of PQconnectPoll, as
    above. Other states may be shown during (and only during) an
    asynchronous connection procedure. These indicate the current
    stage of the connection procedure, and may be useful to provide
    feedback to the user for example. These statuses may include:

        CONNECTION_STARTED: Waiting for connection to be made. 

        CONNECTION_MADE: Connection OK; waiting to send. 

        CONNECTION_AWAITING_RESPONSE: Waiting for a response from the postmaster. 

        CONNECTION_AUTH_OK: Received authentication; waiting for backend startup. 

        CONNECTION_SETENV: Negotiating environment. 

    Note that, although these constants will remain (in order to maintain compatibility) an application should
    never rely upon these appearing in a particular order, or at all, or on the status always being one of these
    documented values. An application may do something like this: 

        switch(PQstatus(conn))
        {
            case CONNECTION_STARTED:
                feedback = "Connecting...";
                break;

            case CONNECTION_MADE:
                feedback = "Connected to server...";
                break;
    .
    .
    .
            default:
                feedback = "Connecting...";
        }



If you happened to add another error state or something that indicated
some other action was required you'd also be breaking compatibility.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Mon, 18 Sep 2000 11:17:19 -0700
Alfred Perlstein <bright@wintelcom.net>
Re: Library versioning
If I change some stuff in a library that forces the user to recompile all
programs because it's not binary compatible I have to change the major
number right? But just changing the order in an enum datatype does not
exactly look like such a big change. But the only way to avoid this problem
is adding the new entries at the end of the enum. Or do I miss something
obvious here?

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Mon, 18 Sep 2000 14:03:01 -0700
Michael Meskes <meskes@postgresql.org>
Library versioning
On Mon, Sep 18, 2000 at 11:17:19AM -0700, Alfred Perlstein wrote:
> If you re-order an exported emum you are going to complete break binary
> compatibility, either bump the major or add the entries at the end.

The later is what I did so far.

> However there's another problem even if you add at the end, namely
> that if previously the 'default' doesn't describe the new values
> then you also break compatibility, for instance:
> ... 
> If you happened to add another error state or something that indicated
> some other action was required you'd also be breaking compatibility.

If the library returns the value, yes. But in my case the library just
accepts two more values. So th eonly problem I can think of is that someone
would try to run a new binary against the old library.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Tue, 19 Sep 2000 14:04:53 -0700
Michael Meskes <meskes@postgresql.org>
Re: Library versioning