Thread: PQnotifies() in 7.3 broken?

PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
Thanks to Rod Taylor's kind help in donating a system account, I've been
able to test libpqxx against postgres 7.3.  Unfortunately, I'm running
into several problems.  One thing that broke libpqxx was a change in 
cursor behaviour that according to Sigurdur Gunnlaugsson seems to be
gone in the 7.4 development tree.  But I'm hitting other snags as well.

When receiving a trigger notification under 7.3, the structure returned
by PQnotifies() appears to be bogus.  In a test I ran, its be_pid was
consistently zero and its relname pointed into never-neverland.

Has anyone else come across this?


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> When receiving a trigger notification under 7.3, the structure returned
> by PQnotifies() appears to be bogus.  In a test I ran, its be_pid was
> consistently zero and its relname pointed into never-neverland.

We changed the PQnotifies result structure in 7.3 (to insulate clients
from the value of NAMEDATALEN).  I think you are compiling your app with
a 7.3 libpq header and then running it with 7.2 libpq code, or possibly
vice versa.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Lee Kindness
Date:
Perhaps the .so name should have been updated for PostgreSQL 7.3? For
example in 7.2 libpq is:
 /usr/lib/libpq.so     -> libpq.so.2.2 /usr/lib/libpq.so.2   -> libpq.so.2.2 /usr/lib/libpq.so.2.0 -> libpq.so.2
/usr/lib/libpq.so.2.2

and PostgreSQL 7.3:
 /usr/lib/libpq.so     -> libpq.so.2.2 /usr/lib/libpq.so.2   -> libpq.so.2.2 /usr/lib/libpq.so.2.0 -> libpq.so.2
/usr/lib/libpq.so.2.2

the same. This would seem to imply binary compatibility?

Lee.

Tom Lane writes:> "Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:> > When receiving a trigger notification under 7.3, the
structurereturned> > by PQnotifies() appears to be bogus.  In a test I ran, its be_pid was> > consistently zero and its
relnamepointed into never-neverland.> We changed the PQnotifies result structure in 7.3 (to insulate clients> from the
valueof NAMEDATALEN).  I think you are compiling your app with> a 7.3 libpq header and then running it with 7.2 libpq
code,or possibly> vice versa.
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Lee Kindness <lkindness@csl.co.uk> writes:
> Perhaps the .so name should have been updated for PostgreSQL 7.3?

It should have been.  If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
too late for that.  Any thoughts out there?
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Lee Kindness <lkindness@csl.co.uk> writes:
> > Perhaps the .so name should have been updated for PostgreSQL 7.3?
> 
> It should have been.  If it wasn't, that was a serious oversight.
> Not sure if we should change it in 7.3.1 or not, though; it may be
> too late for that.  Any thoughts out there?

Seems I did forget.  I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3.  Sorry.

I will update for 7.4 now.  Too late for 7.3 clearly.

Turns out I usually do it when I stamp the new development tree, but
someone else stamped 7.3 and 7.4.  :-(

Here is 7.2 stamp, which shows the updates:revision 1.52date: 2001/05/11 01:46:33;  author: momjian;  state: Exp;
lines:+2 -2Stamp CVS as 7.2.  Update all interface version numbers.  This is thetime to do it, not during beta because
peopleare using this stuff inproduction sometimes.
 

The diff shows:****************** 15,21 ****  # shared library parameters  NAME= pq  SO_MAJOR_VERSION= 2!
SO_MINOR_VERSION=1    override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DFRONTEND-DSYSCONFDIR='"$(sysconfdir)"'  --- 15,21
---- # shared library parameters  NAME= pq  SO_MAJOR_VERSION= 2! SO_MINOR_VERSION= 2
 

so clearly 7.2 and 7.3 have the same minor version for all interfaces.  Bad! 
--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> so clearly 7.2 and 7.3 have the same minor version for all interfaces.  Bad!

We forgot between 7.0 and 7.1 as well, so it's at least consistent...

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > so clearly 7.2 and 7.3 have the same minor version for all interfaces.  Bad!
> 
> We forgot between 7.0 and 7.1 as well, so it's at least consistent...

Yes, seems we increament on every even-numbered release.  ;-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Neil Conway
Date:
On Wed, 2002-12-04 at 13:11, Bruce Momjian wrote:
> Seems I did forget.  I always update the minor for a major release, but
> when development starts, and I seem to have forgotten for 7.3.  Sorry.
> 
> I will update for 7.4 now.  Too late for 7.3 clearly.

Wouldn't that suggest that libpq in 7.4 and 7.3 are *not* binary
compatible? AFAIK that's not the case...

Cheers,

Neil
-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC





Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Neil Conway wrote:
> On Wed, 2002-12-04 at 13:11, Bruce Momjian wrote:
> > Seems I did forget.  I always update the minor for a major release, but
> > when development starts, and I seem to have forgotten for 7.3.  Sorry.
> > 
> > I will update for 7.4 now.  Too late for 7.3 clearly.
> 
> Wouldn't that suggest that libpq in 7.4 and 7.3 are *not* binary
> compatible? AFAIK that's not the case...

I updated the _minor_ version number, which doesn't affect binary
compatibility, I think.  It only makes the newer one more visible.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Lee Kindness
Date:
Bruce Momjian writes:> Tom Lane wrote:> > Lee Kindness <lkindness@csl.co.uk> writes:> > > Perhaps the .so name should
havebeen updated for PostgreSQL 7.3?> > > > It should have been.  If it wasn't, that was a serious oversight.> > Not
sureif we should change it in 7.3.1 or not, though; it may be> > too late for that.  Any thoughts out there?> Seems I
didforget.  I always update the minor for a major release, but> when development starts, and I seem to have forgotten
for7.3.  Sorry.
 

Personally I think automatically updating the version numbers is as
bad as not doing it at all - it misses the point.

The version numbers in shared library filenames denote binary
compatibilty, if the /public/ API changes then the version number
really must be incremented.

If the version increments without any associated API changes then it's
just a PITA for developers and products linking to the PostgreSQL
libraries! It forces recompilation when there is not really a need.

Lee.


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Lee Kindness wrote:
> Bruce Momjian writes:
>  > Tom Lane wrote:
>  > > Lee Kindness <lkindness@csl.co.uk> writes:
>  > > > Perhaps the .so name should have been updated for PostgreSQL 7.3?
>  > > 
>  > > It should have been.  If it wasn't, that was a serious oversight.
>  > > Not sure if we should change it in 7.3.1 or not, though; it may be
>  > > too late for that.  Any thoughts out there?
>  > Seems I did forget.  I always update the minor for a major release, but
>  > when development starts, and I seem to have forgotten for 7.3.  Sorry.
> 
> Personally I think automatically updating the version numbers is as
> bad as not doing it at all - it misses the point.
> 
> The version numbers in shared library filenames denote binary
> compatibilty, if the /public/ API changes then the version number
> really must be incremented.
> 
> If the version increments without any associated API changes then it's
> just a PITA for developers and products linking to the PostgreSQL
> libraries! It forces recompilation when there is not really a need.

It is my understanding that only the major number force recompliation. 
We came up with this procedure after quite a bit of discussion. I am
happy to change it, but I need more than one person to tell me that.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Fernando Nasser
Date:
Bruce Momjian wrote:
> 
> I will update for 7.4 now.  Too late for 7.3 clearly.
> 

Bruce, why is it too late?

Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Fernando Nasser wrote:
> Bruce Momjian wrote:
> > 
> > I will update for 7.4 now.  Too late for 7.3 clearly.
> > 
> 
> Bruce, why is it too late?
> 
> Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.

Oh. yes.  Is it safe to do that?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Fernando Nasser wrote:
>> Bruce Momjian wrote:
>> Bruce, why is it too late?
>> 
>> Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.

> Oh. yes.  Is it safe to do that?

The RPM packagers should probably have a say in this, but I'm leaning
to agree with Fernando.  The bulk of our users probably will not update
from 7.2.* to 7.3 before 7.3.1 is out (at least not for production),
so the fact that 7.3 has the wrong library version number won't affect
them.  But people will continue to get burnt if we don't fix it for
7.3.1.

It is not real clear to me whether we need a major version bump, rather
than a minor one.  We *do* need to signal binary incompatibility.  Who
can clarify the rules here?
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote:
> 
> It is not real clear to me whether we need a major version bump, rather
> than a minor one.  We *do* need to signal binary incompatibility.  Who
> can clarify the rules here?

One thing I wonder about: should the rules make any distinction between
API incompatibilities and client protocol incompatibilities?  For the
former I would imagine one would like to have some "minor" version number
increase whenever features are added and a "major" number be incremented
when changes become incompatible.  For the former, one would probably 
want to have a similar rule but with a dichotomy between server-side
upgrades and client-side upgrades.


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Jeroen T. Vermeulen wrote:
> On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote:
> > 
> > It is not real clear to me whether we need a major version bump, rather
> > than a minor one.  We *do* need to signal binary incompatibility.  Who
> > can clarify the rules here?
> 
> One thing I wonder about: should the rules make any distinction between
> API incompatibilities and client protocol incompatibilities?  For the
> former I would imagine one would like to have some "minor" version number
> increase whenever features are added and a "major" number be incremented
> when changes become incompatible.  For the former, one would probably 
> want to have a similar rule but with a dichotomy between server-side
> upgrades and client-side upgrades.

Yes, now that I remember, that was the big distinction.  One requires a
recompile, the other one doesn't even work with a newer db.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Tom Lane writes:

> It is not real clear to me whether we need a major version bump, rather
> than a minor one.  We *do* need to signal binary incompatibility.  Who
> can clarify the rules here?

Strictly speaking, it's platform-dependent, but our shared library code
plays a bit of abuse with it.  What it comes down to is:

If you change or remove an interface, increment the major version number.
If you add an interface, increment the minor version number.  If you did
neither but changed the source code at all, increment the third version
number, if we had one.

To be thoroughly amused, read the libtool source.  Grep for 'version_type'.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > It is not real clear to me whether we need a major version bump, rather
> > than a minor one.  We *do* need to signal binary incompatibility.  Who
> > can clarify the rules here?
> 
> Strictly speaking, it's platform-dependent, but our shared library code
> plays a bit of abuse with it.  What it comes down to is:
> 
> If you change or remove an interface, increment the major version number.
> If you add an interface, increment the minor version number.  If you did
> neither but changed the source code at all, increment the third version
> number, if we had one.

My take on it is: if you break binary compatibility, which includes
semantic dependencies, then you increment the major version number.
Otherwise you increment the minor version number.

Since the change we're talking about apparently broke binary
compatibility, it calls for a major version number change.


Protocol incompatibility requires a different method of enforcement
altogether.  Incrementing the major number of the library isn't going
to do you any good for that (7.2 clients on remote systems won't have
any idea that the libraries on the 7.3 server have changed that much).


All MHO, of course...


-- 
Kevin Brown                          kevin@sysexperts.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >    This is your .signature virus on drugs:
<>       Any questions?
 


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
OK, seeing that we don't have a third number, do people want me to
increment the interface numbers for 7.3.1, or just wait for the
increment in 7.4?

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > It is not real clear to me whether we need a major version bump, rather
> > than a minor one.  We *do* need to signal binary incompatibility.  Who
> > can clarify the rules here?
> 
> Strictly speaking, it's platform-dependent, but our shared library code
> plays a bit of abuse with it.  What it comes down to is:
> 
> If you change or remove an interface, increment the major version number.
> If you add an interface, increment the minor version number.  If you did
> neither but changed the source code at all, increment the third version
> number, if we had one.
> 
> To be thoroughly amused, read the libtool source.  Grep for 'version_type'.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Philip Warner
Date:
At 06:36 PM 10/12/2002 -0500, Bruce Momjian wrote:
>do people want me to
>increment the interface numbers for 7.3.1

I'd like it because I have to support & build against multiple versions.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/



Re: PQnotifies() in 7.3 broken?

From
Greg Copeland
Date:
Seems like a mistake was made.  Let's (don't ya love how that sounds
like I'm actually involved in the fix? ;)  fix it sooner rather than
later.

Just curious, after a release, how come the numbers are not
automatically bumped to ensure this type thing gets caught sooner rather
than later?  Is it possible to automate this as part of the build
process so that they get grabbed from some version information during
the build?

Greg


On Tue, 2002-12-10 at 17:36, Bruce Momjian wrote:
> OK, seeing that we don't have a third number, do people want me to
> increment the interface numbers for 7.3.1, or just wait for the
> increment in 7.4?
> 
> ---------------------------------------------------------------------------
> 
> Peter Eisentraut wrote:
> > Tom Lane writes:
> > 
> > > It is not real clear to me whether we need a major version bump, rather
> > > than a minor one.  We *do* need to signal binary incompatibility.  Who
> > > can clarify the rules here?
> > 
> > Strictly speaking, it's platform-dependent, but our shared library code
> > plays a bit of abuse with it.  What it comes down to is:
> > 
> > If you change or remove an interface, increment the major version number.
> > If you add an interface, increment the minor version number.  If you did
> > neither but changed the source code at all, increment the third version
> > number, if we had one.
> > 
> > To be thoroughly amused, read the libtool source.  Grep for 'version_type'.
> > 
> > -- 
> > Peter Eisentraut   peter_e@gmx.net
> > 
> > 
-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Greg Copeland wrote:
> Seems like a mistake was made.  Let's (don't ya love how that sounds
> like I'm actually involved in the fix? ;)  fix it sooner rather than
> later.
> 
> Just curious, after a release, how come the numbers are not
> automatically bumped to ensure this type thing gets caught sooner rather
> than later?  Is it possible to automate this as part of the build
> process so that they get grabbed from some version information during
> the build?

Version bump is one of the few things we do at the start of development.
For 7.2, I didn't actually stamp the 7.2 release so I never bumped them,
or I forgot.  Seems I also forgot for 7.1.  It is listed in
tools/RELEASE_CHANGES so it is just a matter of following that file.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Greg Copeland wrote:
>> Is it possible to automate this as part of the build
>> process so that they get grabbed from some version information during
>> the build?

> Version bump is one of the few things we do at the start of
> development.

The real problem here is that major version bump (signifying an
incompatible API change) is something that must NOT be done in an
automated, mindless-checklist way.  We should have executed the bump
when we agreed to change PQnotifies' API incompatibly.  We screwed up
on that.  I think it's correct to fix the error for 7.3.1 --- but we
cannot improve on the situation by making some procedural change to
"always do X at point Y in the release cycle".  Sometimes there's
no substitute for actual thinking :-(
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Greg Copeland wrote:
> >> Is it possible to automate this as part of the build
> >> process so that they get grabbed from some version information during
> >> the build?
> 
> > Version bump is one of the few things we do at the start of
> > development.
> 
> The real problem here is that major version bump (signifying an
> incompatible API change) is something that must NOT be done in an
> automated, mindless-checklist way.  We should have executed the bump
> when we agreed to change PQnotifies' API incompatibly.  We screwed up
> on that.  I think it's correct to fix the error for 7.3.1 --- but we
> cannot improve on the situation by making some procedural change to
> "always do X at point Y in the release cycle".  Sometimes there's
> no substitute for actual thinking :-(

Oh, a major bump.  I thought we did major bumps only in cases where a
recompile will _not_ fix the problem, like changing a parameter value to
a function or removing a function or something like that.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
I have bumped minor versions for 7.3 and 7.4.  If we decide to do
something different later, fine, but this way we will not forget to have
some update for 7.3.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Greg Copeland wrote:
> > >> Is it possible to automate this as part of the build
> > >> process so that they get grabbed from some version information during
> > >> the build?
> > 
> > > Version bump is one of the few things we do at the start of
> > > development.
> > 
> > The real problem here is that major version bump (signifying an
> > incompatible API change) is something that must NOT be done in an
> > automated, mindless-checklist way.  We should have executed the bump
> > when we agreed to change PQnotifies' API incompatibly.  We screwed up
> > on that.  I think it's correct to fix the error for 7.3.1 --- but we
> > cannot improve on the situation by making some procedural change to
> > "always do X at point Y in the release cycle".  Sometimes there's
> > no substitute for actual thinking :-(
> 
> Oh, a major bump.  I thought we did major bumps only in cases where a
> recompile will _not_ fix the problem, like changing a parameter value to
> a function or removing a function or something like that.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Greg Copeland wrote:
> > >> Is it possible to automate this as part of the build
> > >> process so that they get grabbed from some version information during
> > >> the build?
> > 
> > > Version bump is one of the few things we do at the start of
> > > development.
> > 
> > The real problem here is that major version bump (signifying an
> > incompatible API change) is something that must NOT be done in an
> > automated, mindless-checklist way.  We should have executed the bump
> > when we agreed to change PQnotifies' API incompatibly.  We screwed up
> > on that.  I think it's correct to fix the error for 7.3.1 --- but we
> > cannot improve on the situation by making some procedural change to
> > "always do X at point Y in the release cycle".  Sometimes there's
> > no substitute for actual thinking :-(
> 
> Oh, a major bump.  I thought we did major bumps only in cases where a
> recompile will _not_ fix the problem, like changing a parameter value to
> a function or removing a function or something like that.

That's not strictly how the major and minor numbers were intended to
be used, at least as I understand it.

The reason you really have no choice but to bump the major number in
the case of the introduction of binary incompatibilities (whether or
not a recompile would fix it) is that the dynamic linker usually uses
the major version *only* to determine which library to dynamically
link against (but see below for a caveat).

So what's the purpose of the minor version number?  To indicate which
revision of the library is in use.  It may be that version 2.1 has
bugfixes that 2.0 doesn't have, so the minor version number allows you
to determine whether or not you have the fixes in question.

Generally, you can specify at library build time whether an
application must link with a specific major/minor numbered library, or
whether it can link against any library with the same major number.
Most people do the latter, and that's as it should be.  If the
PostgreSQL libraries (for instance) required a match against the minor
number, then applications would have to be recompiled every time
PostgreSQL was upgraded.  Not only is that highly undesirable, for
some it may not even be possible (e.g., when using commercial
applications).



-- 
Kevin Brown                          kevin@sysexperts.com


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> OK, seeing that we don't have a third number, do people want me to
> increment the interface numbers for 7.3.1, or just wait for the
> increment in 7.4?

ISTM that the briefly established strategy to bump the version numbers at
the beginning of development is not satisfactory.  The reason is that the
"beginning" is in many cases not well-defined.  Example 1: If we hadn't
noticed the PQnotifies() problem that started this thread we would have
forgotten again.  Example 2: If someone put a fix of some sort in libpq
for 7.3.1, we would surely forget to bump the version number.

Consequence: The library version number must be bumped as part of the
release preparation, as is in fact written down in the release checklist.
And such a bump should be done only after reviewing the change history of
the library during that development cycle to determine if a major bump is
necessary or if in fact no change at all is warranted.

As for what to do right now, if others agree I would suggest that we do
the appropriate version number adjustments (as described in the previous
paragraph) for 7.3.1.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > OK, seeing that we don't have a third number, do people want me to
> > increment the interface numbers for 7.3.1, or just wait for the
> > increment in 7.4?
> 
> ISTM that the briefly established strategy to bump the version numbers at
> the beginning of development is not satisfactory.  The reason is that the

We bump at the beginning only because we _know_ we want new users to use
the newer library.  (Does the runtime linker know to get the highest
minor numbered library with the same major number?)

Bumping at the end is done only when we know there is some change. The
big question is whether a change in the API or a change in the code
(recompile) is enough to bump that major version number.  We always make
some force-recompile change in the library in each release, don't we? 
Do we just bump the major in every major release?

> "beginning" is in many cases not well-defined.  Example 1: If we hadn't
> noticed the PQnotifies() problem that started this thread we would have
> forgotten again.  Example 2: If someone put a fix of some sort in libpq
> for 7.3.1, we would surely forget to bump the version number.
> 
> Consequence: The library version number must be bumped as part of the
> release preparation, as is in fact written down in the release checklist.

I usually bumped the minor at the beginning because this allows beta
testers to not have _extra_ versions of the library laying around, and
also because we make minor library changes often during beta, so it
isn't clear when to bump that number.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Bruce Momjian wrote:
> We bump at the beginning only because we _know_ we want new users to use
> the newer library.  (Does the runtime linker know to get the highest
> minor numbered library with the same major number?)

It probably depends on the system, but the runtime linker isn't that
smart under Linux.  It looks for a match for the major version only,
so for instance in the case of libpq major version 2, it'll look for
libpq.so.2 in the library search path.  Multiple minor versions of the
library are managed via symlinks under Linux (libpq.so.2 ->
libpq.so.2.2, for instance).

> Bumping at the end is done only when we know there is some change. The
> big question is whether a change in the API or a change in the code
> (recompile) is enough to bump that major version number.  We always make
> some force-recompile change in the library in each release, don't we? 
> Do we just bump the major in every major release?

It wouldn't be a terribly bad idea to do that, but the main criteria
for bumping the major version should be binary compatibility.  If
applications which link against libpq.so.2 reside on the system and
libpq.so.2.3 has binary incompatibilities with libpq.so.2.2, then
installing libpq.so.2.3 on the system will break all the binaries that
use libpq.so.2.  That's why it's important to bump the major version
when there are binary incompatibilities: you can install libpq.so.3
and all the while, applications that rely on libpq.so.2 will still run
(because you can have both of those library versions installed on the
system at the same time without conflict).

> I usually bumped the minor at the beginning because this allows beta
> testers to not have _extra_ versions of the library laying around, and
> also because we make minor library changes often during beta, so it
> isn't clear when to bump that number.

I think it makes sense to change the minor number whenever there are
code changes to the library that don't introduce binary
incompatibilities.  Whether you bump the minor version during a new
release when there are no changes to the library itself is probably a
matter of preference only.  It doesn't really hurt anything and may
make management of the version number easier.



-- 
Kevin Brown                          kevin@sysexperts.com


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Kevin Brown wrote:
> It wouldn't be a terribly bad idea to do that, but the main criteria
> for bumping the major version should be binary compatibility.  If
> applications which link against libpq.so.2 reside on the system and
> libpq.so.2.3 has binary incompatibilities with libpq.so.2.2, then
> installing libpq.so.2.3 on the system will break all the binaries that
> use libpq.so.2.  That's why it's important to bump the major version
> when there are binary incompatibilities: you can install libpq.so.3
> and all the while, applications that rely on libpq.so.2 will still run
> (because you can have both of those library versions installed on the
> system at the same time without conflict).
> 
> > I usually bumped the minor at the beginning because this allows beta
> > testers to not have _extra_ versions of the library laying around, and
> > also because we make minor library changes often during beta, so it
> > isn't clear when to bump that number.
> 
> I think it makes sense to change the minor number whenever there are
> code changes to the library that don't introduce binary
> incompatibilities.  Whether you bump the minor version during a new
> release when there are no changes to the library itself is probably a
> matter of preference only.  It doesn't really hurt anything and may
> make management of the version number easier.

If it is true that the linker only matches the major number, what value
is there in incrementing the minor number, as we have done in the past?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Bruce Momjian wrote:
> If it is true that the linker only matches the major number, what value
> is there in incrementing the minor number, as we have done in the
> past?

It's main value is in indicating to the system administrator which
version of the library he has.  This is particularly useful in the
face of security updates.

A library can have bugfixes (even significant ones) and still be
binary compatible with a previous revision.  Situations like that are
what the minor number is useful for.  It can make the developer's (or
administrator's) life a little easier, since it means he can have
multiple minor revisions installed on his system and change the major
revision symlink to point to whichever one he wishes to actually use
(given the way the dynamic linker works, the administrator can name
the actual target of the symlink whatever he wishes so it's not
mandatory that the developers do that for him...it just makes his life
easier).

I probably should have gone into a little more detail about how the
linker does its thing: it looks for a literal match for what the
application says it was compiled against.  When the application was
linked, if the library it was linked against said it was 'libpg.so.2'
(As far as I know, the compile-time linker retrieves this from the
library's header information, not from its filename), then that's what
gets stored in the application's executable header and is what the
runtime linker looks for.  libpg.so.2 may be a symlink to (e.g.) 
libpg.so.2.1 or a hard link, or a copy of a library for that matter.
The runtime linker will successfully link the shared library into the
program's memory image in any of those cases -- it only has to find a
shared library whose filename is the same as what's requested *and*
whose header information provides the same name.



-- 
Kevin Brown                          kevin@sysexperts.com


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> We bump at the beginning only because we _know_ we want new users to use
> the newer library.  (Does the runtime linker know to get the highest
> minor numbered library with the same major number?)

No, the run-time linker only looks at the major version.

> Bumping at the end is done only when we know there is some change.

That is the theory.  But the practice is that we should, as you suggest,
reconsider the issue at the end but we don't because we all think we
already did it at the beginning.  That considerably confuses the issue for
no real gain.  During the development cycle the version number is pretty
irrelevant because it is more likely that the code is broken than that
there is a genuine library conflict that could be usefully resolved.

> The big question is whether a change in the API or a change in the code
> (recompile) is enough to bump that major version number.  We always make
> some force-recompile change in the library in each release, don't we?
> Do we just bump the major in every major release?

The rules are pretty clear:  If you change or remove an interface (= part
of the API) then you change the major, if you add an interface or
"improve" the code, change the minor.  Whether we actually change the code
during a release cycle is something that is best determined *after* the
release cycle.  Possibly we always do, but I wouldn't be surprised if some
library like pgeasy lay dormant for a while.

> I usually bumped the minor at the beginning because this allows beta
> testers to not have _extra_ versions of the library laying around, and

That doesn't make sense to me.  Which extra versions?

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > We bump at the beginning only because we _know_ we want new users to use
> > the newer library.  (Does the runtime linker know to get the highest
> > minor numbered library with the same major number?)
> 
> No, the run-time linker only looks at the major version.

Then what value is there to incrementing the minor number?

> > The big question is whether a change in the API or a change in the code
> > (recompile) is enough to bump that major version number.  We always make
> > some force-recompile change in the library in each release, don't we?
> > Do we just bump the major in every major release?
> 
> The rules are pretty clear:  If you change or remove an interface (= part
> of the API) then you change the major, if you add an interface or
> "improve" the code, change the minor.  Whether we actually change the code

So if a recompile fixes it, increment minor, else major.  Then we
normally only do minor-level changes,. and frankly we improve the code
all during development time and during beta, so it seems pretty abitrary
when we increment the minor unless we want to increment it many times
during development, _or_ right before final to ensure that final
releaase users have the newest version.


> during a release cycle is something that is best determined *after* the
> release cycle.  Possibly we always do, but I wouldn't be surprised if some
> library like pgeasy lay dormant for a while.
> 
> > I usually bumped the minor at the beginning because this allows beta
> > testers to not have _extra_ versions of the library laying around, and
> 
> That doesn't make sense to me.  Which extra versions?

If you bump during beta, and don't delete your pgsql/ directory, you
will have the old libpq.so there and the new one because once you bump
the version, the old one just says in the directory.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So if a recompile fixes it, increment minor, else major.

Wrong --- if you need a recompile then it's not binary-compatible, so
it should be a major version bump.

> Then we
> normally only do minor-level changes,. and frankly we improve the code
> all during development time and during beta, so it seems pretty abitrary
> when we increment the minor unless we want to increment it many times
> during development, _or_ right before final to ensure that final
> releaase users have the newest version.

I think there is definite value in incrementing the minor version once
at the start of the cycle.  Whether we do it at start or end does not
matter to end users, but it *does* help developers, who can then easily
tell whether they are looking at a devel library or the previous
release.

If we make a non-binary-compatible change during a development cycle,
we should then immediately bump the major version number.  Leaving it
till the end of the cycle is an excellent recipe for forgetting, as
indeed we just did.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > So if a recompile fixes it, increment minor, else major.
> 
> Wrong --- if you need a recompile then it's not binary-compatible, so
> it should be a major version bump.

But the previous poster said only API changes were reasons to bump the
major, right?
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Wrong --- if you need a recompile then it's not binary-compatible, so
>> it should be a major version bump.

> But the previous poster said only API changes were reasons to bump the
> major, right?

Yes.  He meant *binary* API changes, though, ie, anything that would
break extant executables originally linked to the prior version of the
shared library.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Wrong --- if you need a recompile then it's not binary-compatible, so
> >> it should be a major version bump.
> 
> > But the previous poster said only API changes were reasons to bump the
> > major, right?
> 
> Yes.  He meant *binary* API changes, though, ie, anything that would
> break extant executables originally linked to the prior version of the
> shared library.

Just for clarification --- don't most/all our releases make a binary
change that needs are compile?  Actually, you are saying a recompile of
the client, right?  Yes, we do those rarely, and in 7.3, for the NOTIFY
structure change.  What we do often is want old binaries to use our new
libraries.  That isn't a major bump requirement, right?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Just for clarification --- don't most/all our releases make a binary
> change that needs are compile?

No, they usually don't.  Adding new routines, for example, does not
break existing clients.

> What we do often is want old binaries to use our new
> libraries.  That isn't a major bump requirement, right?

Exactly.  A major bump means that they can't use it.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
OK, so what do we do with 7.3.1.  Increment major or minor?

---------------------------------------------------------------------------

pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Tom Lane wrote:
> > >> Wrong --- if you need a recompile then it's not binary-compatible, so
> > >> it should be a major version bump.
> > 
> > > But the previous poster said only API changes were reasons to bump the
> > > major, right?
> > 
> > Yes.  He meant *binary* API changes, though, ie, anything that would
> > break extant executables originally linked to the prior version of the
> > shared library.
> 
> Just for clarification --- don't most/all our releases make a binary
> change that needs are compile?  Actually, you are saying a recompile of
> the client, right?  Yes, we do those rarely, and in 7.3, for the NOTIFY
> structure change.  What we do often is want old binaries to use our new
> libraries.  That isn't a major bump requirement, right?
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, so what do we do with 7.3.1.  Increment major or minor?

Major.  I thought you did it already?
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, so what do we do with 7.3.1.  Increment major or minor?
> 
> Major.  I thought you did it already?

I did only minor, which I knew was safe.  Do folks realize this will
require recompile of applications by 7.3 users moving to 7.3.1?  That
seems very drastic, and there have been very few problem reports about
the NOTIFY change.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Lee Kindness
Date:
Making something binary incompatible IS an API change! In the case in
question an externally visible structure definition was changed -
clearly a change of API...

Bruce Momjian writes:> Tom Lane wrote:> > Bruce Momjian <pgman@candle.pha.pa.us> writes:> > > So if a recompile fixes
it,increment minor, else major.> > > > Wrong --- if you need a recompile then it's not binary-compatible, so> > it
shouldbe a major version bump.> > But the previous poster said only API changes were reasons to bump the> major,
right?


Library Versions (was: PQnotifies() in 7.3 broken?)

From
Lee Kindness
Date:
Guys, can I take this chance to summarise the thread and when the
major and minor versions should be updated, perhaps could be added to
the developers FAQ if everyone is in agreement?

Major Version
=============

The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but limited to:

1. Removing a public function or structure (or typedef, enum, ...)

2. Modifying a public functions arguments.

3. Removing a field from a public structure.

3. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.

Adding a new function would NOT force an increase in the major version
number. When the major version is increased all applications which
link to the library MUST be recompiled - this is not desirable. When
the major version is updated the minor version gets reset.

Minor Version
=============

The minor version number should be updated whenever the functionality
of the library has changed, typically and change in source code
between releases would mean an increase in the minor version number so
long as it does not require a major version increase.

Thanks, Lee.


Library Versions (was: PQnotifies() in 7.3 broken?)

From
Lee Kindness
Date:
Guys,

Some further comments on bumbing the major version number which aren't
so cut-n-dry...

Lee Kindness writes:> The major version number should be updated whenever the source of the> library changes to make it
binaryincompatible. Such changes include,> but limited to:> > 1. Removing a public function or structure (or typedef,
enum,...)> > 2. Modifying a public functions arguments.> > 3. Removing a field from a public structure.> > 3. Adding a
fieldto a public structure, unless steps have been> previously taken to shield users from such a change, for example
by>such structures only ever being allocated/instantiated by a library> function which would give the new field a
suitabledefault value.
 

For #2 steps could be taken to maintain binary compatibility across
minor PostgreSQL releases (e.g. the 7.2 series, the 7.3 series, the
7.4/8.0 series). Consider the following function
void print_stuff(int arg1, int arg2){  printf("stuff: %d %d\n", arg1, arg2);}

If we wanted to add a third argument:
void print_stuff(int arg1, int arg2, int arg3){  printf("stuff: %d %d %d\n", arg1, arg2, arg3);}

Then doing it like this:
void print_stuff2(int arg1, int arg2, int arg3){  printf("stuff: %d %d %d\n", arg1, arg2, arg3);}
void print_stuff(int arg1, int arg2){  print_stuff(arg1, arg2, 0);}

would maintain binary compatibility. Obviously this would add a fair
bit of cruft if used extensively, but considering the changes between
minor versions would probably be worthwhile to avoid bumping library
major version. Naturally in the next major version print_stuff() would
assume the functionality and arguments of print_stuff2().

Lee.


Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Fri, Dec 13, 2002 at 12:34:58AM -0500, Bruce Momjian wrote:
> 
> I did only minor, which I knew was safe.  Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1?  That
> seems very drastic, and there have been very few problem reports about
> the NOTIFY change.

In my case, I only know it broke some test cases.  But still, isn't it
better to err on the safe side and at least give the user a clue that
the upgrade isn't necessarily supposed to work with his existing code?


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Oliver Elphick
Date:
On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > OK, so what do we do with 7.3.1.  Increment major or minor?
> > 
> > Major.  I thought you did it already?
> 
> I did only minor, which I knew was safe.  Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1?  That
> seems very drastic, and there have been very few problem reports about
> the NOTIFY change.

If the ABI is different, they need to recompile but don't have any
indication of it.  This is bad.

If the major number changes, they can keep the old library around for
the benefits of applications that have not yet been recompiled, while
newly compiled applications can use the new library

So please change it.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "For thou art my hope, O Lord GOD; thou art my trust      from my youth."
          Psalms 71:5 
 



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Lee Kindness wrote:
> Making something binary incompatible IS an API change! In the case in
> question an externally visible structure definition was changed -
> clearly a change of API...

My point was that I thought it was a source-level API change that
required a major bump.  I now see it can be a binary change too, so
anything that requires a client recompile is a major bump.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Oliver Elphick wrote:
> On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > OK, so what do we do with 7.3.1.  Increment major or minor?
> > > 
> > > Major.  I thought you did it already?
> > 
> > I did only minor, which I knew was safe.  Do folks realize this will
> > require recompile of applications by 7.3 users moving to 7.3.1?  That
> > seems very drastic, and there have been very few problem reports about
> > the NOTIFY change.
> 
> If the ABI is different, they need to recompile but don't have any
> indication of it.  This is bad.
> 
> If the major number changes, they can keep the old library around for
> the benefits of applications that have not yet been recompiled, while
> newly compiled applications can use the new library
> 
> So please change it.

The point is that we are changing it for 7.3.1, so though 7.3 libpq is
almost identical to 7.3.1 libpq, we are going to bump the major and
force recompile.  The binary API change was from 7.2 to 7.3, not 7.3 to
7.3.1.  Do people still want a major bump in 7.3.1?

Clearly we should have bumped the major in 7.3, but we didn't.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The point is that we are changing it for 7.3.1, so though 7.3 libpq is
> almost identical to 7.3.1 libpq, we are going to bump the major and
> force recompile.  The binary API change was from 7.2 to 7.3, not 7.3 to
> 7.3.1.  Do people still want a major bump in 7.3.1?

Yes.  We already discussed this: the consensus was that it's better to
inconvenience the early adopters of 7.3 than leave a time bomb sitting
there throughout the 7.3.* cycle.

BTW, if we do make a major bump, that would suggest we ought to get
7.3.1 out as soon as possible, so as to minimize the uptake of 7.3.
I have been thinking that a mid-Dec release of 7.3.1 would be a good
plan anyway, since we already know of several moderately serious bugs
in 7.3.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The point is that we are changing it for 7.3.1, so though 7.3 libpq is
> > almost identical to 7.3.1 libpq, we are going to bump the major and
> > force recompile.  The binary API change was from 7.2 to 7.3, not 7.3 to
> > 7.3.1.  Do people still want a major bump in 7.3.1?
> 
> Yes.  We already discussed this: the consensus was that it's better to
> inconvenience the early adopters of 7.3 than leave a time bomb sitting
> there throughout the 7.3.* cycle.
> 
> BTW, if we do make a major bump, that would suggest we ought to get
> 7.3.1 out as soon as possible, so as to minimize the uptake of 7.3.
> I have been thinking that a mid-Dec release of 7.3.1 would be a good
> plan anyway, since we already know of several moderately serious bugs
> in 7.3.

OK, let me see if I understand the ramifications.

If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and
you your old binaries will continue to work.  However, if you delete the
old libraries, then install, anything compiled against 7.3 will not work
until it is recompiled.

Also, any new linking against a 7.3.1 that has both major version
numbers will use the newer major?  Is that right?

(I honestly never understood all this before.)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> > No, the run-time linker only looks at the major version.
>
> Then what value is there to incrementing the minor number?

For those platforms that have an ldconfig program, the ldconfig will
update the symlinks to the shared library based on the minor version
number.  So if you have installed somewhere
   libpq.so.2.2   libpq.so.2.3

then ldconfig will create a symlink
   libpq.so.2 -> libpq.so.2.3

because that is the newest/best version.  Note that "libpq.so.2" is the
file name that the dynamic loader will actually look for.

Other platforms probably have a mechanism that comes out to the same
effect.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Oliver Elphick
Date:
On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote:
> OK, let me see if I understand the ramifications.
> 
> If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and
> you your old binaries will continue to work.  However, if you delete the
> old libraries, then install, anything compiled against 7.3 will not work
> until it is recompiled.

Yes.  You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
from 7.3 (and also from 7.2.x, though in fact they are different).  If
you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
(symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to
libpq.so.2.2) from an earlier release.

> 
> Also, any new linking against a 7.3.1 that has both major version
> numbers will use the newer major?  Is that right?

7.3.1 will only have the new major version number; the old one will have
come from 7.3 or earlier.  The library chosen by the linker is the one
linked to libpq.so.


-- 
Oliver Elphick <olly@lfix.co.uk>
LFIX Limited



Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Fri, Dec 13, 2002 at 09:06:47PM +0000, Oliver Elphick wrote:
> 
> Yes.  You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> from 7.3 (and also from 7.2.x, though in fact they are different).  If
> you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
> (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to
> libpq.so.2.2) from an earlier release.

Doesn't that mean that a user upgrading from 7.3 to 7.3.1 will have two
libraries, libpq.so.2.2 and libpq.so.3, that both adhere to the 7.3 ABI?

Perhaps 7.3.1 could include a true, 7.2-style libpq.so.2.2 to overwrite
any 7.3-style version that the original 7.3 may have installed under that
name?


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Jeroen T. Vermeulen wrote:
> On Fri, Dec 13, 2002 at 09:06:47PM +0000, Oliver Elphick wrote:
> > 
> > Yes.  You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> > from 7.3 (and also from 7.2.x, though in fact they are different).  If
> > you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
> > (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to
> > libpq.so.2.2) from an earlier release.
> 
> Doesn't that mean that a user upgrading from 7.3 to 7.3.1 will have two
> libraries, libpq.so.2.2 and libpq.so.3, that both adhere to the 7.3 ABI?
> 
> Perhaps 7.3.1 could include a true, 7.2-style libpq.so.2.2 to overwrite
> any 7.3-style version that the original 7.3 may have installed under that
> name?

That's an interesting idea, but then 7.3 binaries would link to
libpq.so.2.2, which is bad.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Jeroen T. Vermeulen wrote:
>> Perhaps 7.3.1 could include a true, 7.2-style libpq.so.2.2 to overwrite
>> any 7.3-style version that the original 7.3 may have installed under that
>> name?

> That's an interesting idea, but then 7.3 binaries would link to
> libpq.so.2.2, which is bad.

There are a number of problems with that, but the biggie is that the old
binary API is inherently dependent on NAMEDATALEN.  We can *not* ship a
library that is both 100% backwards compatible and 100% compatible to
a standard-issue 7.3 server.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > OK, so what do we do with 7.3.1.  Increment major or minor?
> > 
> > Major.  I thought you did it already?
> 
> I did only minor, which I knew was safe.  Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1?  That
> seems very drastic, and there have been very few problem reports about
> the NOTIFY change.

Keep in mind that people who are running applications compiled against
the older (7.2) library have the option of keeping the older library
around.  They can recompile their applications to link against the
newer library at their leisure.

Someone who has recompiled their applications against the 7.3
libraries is already safe -- they can install 7.3.1 and keep the old
7.3 libraries around at the same time if they don't want to recompile
their applications again.  They just have to be careful to not use any
precompiled applications that were linked against the 7.2 series.

The people who are running 7.2 have the option of keeping their 7.2
libraries around while upgrading to 7.3.1.  Any applications that are
compiled against the 7.2 libraries will still work.

The only people who are in trouble are the people who upgraded from
7.2 to 7.3 but did not recompile some of their applications.  They
have three options: install 7.3.1 and recompile their applications,
install 7.3.1 and reinstall the 7.2 shared libraries, or recompile
their applications against 7.3 (and then upgrade to 7.3.1 at their
leisure).  Obviously the last option is the worst of the lot: if
they're going to recompile their applications, they may as well do so
against the newer (7.3.1) libraries with a higher major number so
there is no confusion about which libraries are really compatible with
which.


-- 
Kevin Brown                          kevin@sysexperts.com


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
OK, I have updated the libpq major number in 7.3.X, and updated major
and minor in HEAD. Do I need to increment the other interfaces that
_use_ libpq, like ecpg?  I think so.

---------------------------------------------------------------------------

Oliver Elphick wrote:
> On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote:
> > OK, let me see if I understand the ramifications.
> > 
> > If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and
> > you your old binaries will continue to work.  However, if you delete the
> > old libraries, then install, anything compiled against 7.3 will not work
> > until it is recompiled.
> 
> Yes.  You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> from 7.3 (and also from 7.2.x, though in fact they are different).  If
> you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
> (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to
> libpq.so.2.2) from an earlier release.
> 
> > 
> > Also, any new linking against a 7.3.1 that has both major version
> > numbers will use the newer major?  Is that right?
> 
> 7.3.1 will only have the new major version number; the old one will have
> come from 7.3 or earlier.  The library chosen by the linker is the one
> linked to libpq.so.
> 
> 
> -- 
> Oliver Elphick <olly@lfix.co.uk>
> LFIX Limited
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Library Versions (was: PQnotifies() in 7.3 broken?)

From
Bruce Momjian
Date:
OK, I have added this to tools/RELEASE_CHANGES. New file attached.

---------------------------------------------------------------------------

Lee Kindness wrote:
> Guys, can I take this chance to summarise the thread and when the
> major and minor versions should be updated, perhaps could be added to
> the developers FAQ if everyone is in agreement?
>
> Major Version
> =============
>
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but limited to:
>
> 1. Removing a public function or structure (or typedef, enum, ...)
>
> 2. Modifying a public functions arguments.
>
> 3. Removing a field from a public structure.
>
> 3. Adding a field to a public structure, unless steps have been
> previously taken to shield users from such a change, for example by
> such structures only ever being allocated/instantiated by a library
> function which would give the new field a suitable default value.
>
> Adding a new function would NOT force an increase in the major version
> number. When the major version is increased all applications which
> link to the library MUST be recompiled - this is not desirable. When
> the major version is updated the minor version gets reset.
>
> Minor Version
> =============
>
> The minor version number should be updated whenever the functionality
> of the library has changed, typically and change in source code
> between releases would mean an increase in the minor version number so
> long as it does not require a major version increase.
>
> Thanks, Lee.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
* Version numbers
    configure.in and configure
    bump interface version numbers
      o src/interfaces/*/Makefile
      o src/interfaces/libpq/libpq.rc
      o src/include/pg_config.h.win32

* Release notes
    update HISTORY and later doc/src/sgml/release.sgml

* Documentation
    document all new features
    update help output from inside the programs
    doc/src/sgml/ref manual pages

* Ports
    update ports list in doc/src/sgml/installation.sgml
    platform-specific FAQ's, if needed

* Miscellaneous files
    doc/bug.template

* Update pg_upgrade to handle new version, or disable

* Update copyright year?


---------------------------------------------------------------------------

Major Version
=============

The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited to:

1. Removing a public function or structure (or typedef, enum, ...)

2. Modifying a public functions arguments.

3. Removing a field from a public structure.

3. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.

Adding a new function would NOT force an increase in the major version
number. When the major version is increased all applications which
link to the library MUST be recompiled - this is not desirable. When
the major version is updated the minor version gets reset.

Minor Version
=============

The minor version number should be updated whenever the functionality
of the library has changed, typically and change in source code
between releases would mean an increase in the minor version number so
long as it does not require a major version increase.

Minimizing Changes
==================

When modifying public functions arguments, steps should be taken to
maintain binary compatibility across minor PostgreSQL releases (e.g. the
7.2 series, the 7.3 series, the 7.4/8.0 series). Consider the following
function:

    void print_stuff(int arg1, int arg2)
    {
        printf("stuff: %d %d\n", arg1, arg2);
    }

If we wanted to add a third argument:

    void print_stuff(int arg1, int arg2, int arg3)
    {
        printf("stuff: %d %d %d\n", arg1, arg2, arg3);
    }

Then doing it like this:

    void print_stuff2(int arg1, int arg2, int arg3)
    {
        printf("stuff: %d %d %d\n", arg1, arg2, arg3);
    }

    void print_stuff(int arg1, int arg2)
    {
        print_stuff(arg1, arg2, 0);
    }

would maintain binary compatibility. Obviously this would add a fair
bit of cruft if used extensively, but considering the changes between
minor versions would probably be worthwhile to avoid bumping library
major version. Naturally in the next major version print_stuff() would
assume the functionality and arguments of print_stuff2().


Lee Kindness

Re: Library Versions (was: PQnotifies() in 7.3 broken?)

From
Bruce Momjian
Date:
I have added this info too.

---------------------------------------------------------------------------

Lee Kindness wrote:
> Guys,
> 
> Some further comments on bumbing the major version number which aren't
> so cut-n-dry...
> 
> Lee Kindness writes:
>  > The major version number should be updated whenever the source of the
>  > library changes to make it binary incompatible. Such changes include,
>  > but limited to:
>  > 
>  > 1. Removing a public function or structure (or typedef, enum, ...)
>  > 
>  > 2. Modifying a public functions arguments.
>  > 
>  > 3. Removing a field from a public structure.
>  > 
>  > 3. Adding a field to a public structure, unless steps have been
>  > previously taken to shield users from such a change, for example by
>  > such structures only ever being allocated/instantiated by a library
>  > function which would give the new field a suitable default value.
> 
> For #2 steps could be taken to maintain binary compatibility across
> minor PostgreSQL releases (e.g. the 7.2 series, the 7.3 series, the
> 7.4/8.0 series). Consider the following function
> 
>  void print_stuff(int arg1, int arg2)
>  {
>    printf("stuff: %d %d\n", arg1, arg2);
>  }
> 
> If we wanted to add a third argument:
> 
>  void print_stuff(int arg1, int arg2, int arg3)
>  {
>    printf("stuff: %d %d %d\n", arg1, arg2, arg3);
>  }
> 
> Then doing it like this:
> 
>  void print_stuff2(int arg1, int arg2, int arg3)
>  {
>    printf("stuff: %d %d %d\n", arg1, arg2, arg3);
>  }
> 
>  void print_stuff(int arg1, int arg2)
>  {
>    print_stuff(arg1, arg2, 0);
>  }
> 
> would maintain binary compatibility. Obviously this would add a fair
> bit of cruft if used extensively, but considering the changes between
> minor versions would probably be worthwhile to avoid bumping library
> major version. Naturally in the next major version print_stuff() would
> assume the functionality and arguments of print_stuff2().
> 
> Lee.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
I figured out why I forgot to update the minor number for 7.3.  The old
RELEASE_CHANGES file had:
   bump interface version numbers     o src/interfaces/libpq/libpq.rc     o src/include/pg_config.h.win32

I had forgotten to explicitly list the Makefile changes.

The new list is:
   bump interface version numbers     o src/interfaces/*/Makefile     o src/interfaces/libpq/libpq.rc     o
src/include/pg_config.h.win32

Of course, incrementing the minor number may not have even helped us
because we needed a major increase, which I didn't understand at the
time.

---------------------------------------------------------------------------

Oliver Elphick wrote:
> On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote:
> > OK, let me see if I understand the ramifications.
> > 
> > If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and
> > you your old binaries will continue to work.  However, if you delete the
> > old libraries, then install, anything compiled against 7.3 will not work
> > until it is recompiled.
> 
> Yes.  You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> from 7.3 (and also from 7.2.x, though in fact they are different).  If
> you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
> (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to
> libpq.so.2.2) from an earlier release.
> 
> > 
> > Also, any new linking against a 7.3.1 that has both major version
> > numbers will use the newer major?  Is that right?
> 
> 7.3.1 will only have the new major version number; the old one will have
> come from 7.3 or earlier.  The library chosen by the linker is the one
> linked to libpq.so.
> 
> 
> -- 
> Oliver Elphick <olly@lfix.co.uk>
> LFIX Limited
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Oliver Elphick
Date:
On Sat, 2002-12-14 at 18:59, Bruce Momjian wrote:
> OK, I have updated the libpq major number in 7.3.X, and updated major
> and minor in HEAD. Do I need to increment the other interfaces that
> _use_ libpq, like ecpg?  I think so.

I don't think so.

$ ldd /usr/lib/postgresql/lib/libecpg.solibpq.so.2 => /usr/lib/libpq.so.2 (0x40019000)libc.so.6 => /lib/libc.so.6
(0x4002e000)libssl.so.0.9.6=> /usr/lib/i686/libssl.so.0.9.6 (0x40141000)libcrypto.so.0.9.6 =>
/usr/lib/i686/libcrypto.so.0.9.6(0x4016e000)libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x40226000)libcrypt.so.1 =>
/lib/libcrypt.so.1(0x4025c000)libresolv.so.2 => /lib/libresolv.so.2 (0x40289000)libnsl.so.1 => /lib/libnsl.so.1
(0x4029a000)/lib/ld-linux.so.2=> /lib/ld-linux.so.2 (0x80000000)libdl.so.2 => /lib/libdl.so.2
(0x402ad000)libcom_err.so.1=> /usr/lib/libcom_err.so.1 (0x402b0000)libasn1.so.5 => /usr/lib/libasn1.so.5
(0x402b2000)libroken.so.9=> /usr/lib/libroken.so.9 (0x402d2000)libdb3.so.3 => /usr/lib/libdb3.so.3 (0x402e3000)
 


Here libecpg will look for libpq.so.2.  When 7.3.1 is released, this
libecpg will be replaced by one that looks for libpq.so.3.  But I think
that, unless the API of libecpg changes, its version should stay the
same.

If you change it with libpq, you must also change it with all the other
libraries it links in, like libkrb5 and libdb3.  That is clearly
impracticable.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "But I will hope continually, and will yet praise thee      more and more."
               Psalms 71:14 
 



Re: PQnotifies() in 7.3 broken?

From
Kevin Brown
Date:
Bruce Momjian wrote:
> 
> OK, I have updated the libpq major number in 7.3.X, and updated major
> and minor in HEAD. Do I need to increment the other interfaces that
> _use_ libpq, like ecpg?  I think so.

You'll only need to increment the major number of those other
interfaces that are no longer binary-compatible with their immediate
predecessors.

That is, if the version of libecpg that ships with 7.3.1 is
incompatible with the version of libecpg that ships with 7.3, then you
should bump its major number (the one that shipped with 7.3 should
have had its major number bumped if it was incompatible with the one
that shipped with 7.2.3).  But its binary interface should be
independent of the binary interface of libpg.

When you build a shared library, you link it against any shared
libraries it depends on.  The resulting dependency list is contained
within the shared library the same way it's contained in an
application.  You can run ldd on shared libraries just as you can on
applications.


It might be helpful to think of the major number as being the same as
a protocol description number.  You change the protocol description
number when you make changes to the protocol that would make a server
using the new version of the protocol incompatible with a client using
the old version of the protocol.

In fact, there's really very little conceptual difference between a
protocol and an API: both are a means for two entities to communicate
with one another.  Change the API and you have to do something to make
it clear that the API has changed.  Same deal with a protocol.


I don't know if what I'm saying here makes much sense to you, but I
hope it helps...



-- 
Kevin Brown                          kevin@sysexperts.com


Re: PQnotifies() in 7.3 broken?

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Do I need to increment the other interfaces that
> _use_ libpq, like ecpg?

If and only if the libpq API is part of their documented API.  For ecpg I
think this is not the case, but for libpq++ it would seem to be the case.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Do I need to increment the other interfaces that
>> _use_ libpq, like ecpg?

> If and only if the libpq API is part of their documented API.  For ecpg I
> think this is not the case, but for libpq++ it would seem to be the case.

However, an app linked against libpq++ would also be linked against
libpq, and so the incompatibility will be flagged by the linker anyway.
I can see no need to bump libpq++'s own number.
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Sun, Dec 15, 2002 at 11:21:07AM -0500, Tom Lane wrote:
> 
> However, an app linked against libpq++ would also be linked against
> libpq, and so the incompatibility will be flagged by the linker anyway.
> I can see no need to bump libpq++'s own number.

Plus, of course, libpq++ being a C++ library will break compatibility at
some compiler upgrades--which isn't even necessarily visible to anyone
compiling a postgres release.


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Greg Copeland
Date:
But it's something they should of already had to do.  We're just paying
late for old sins.  ;)  

Greg


On Thu, 2002-12-12 at 23:34, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > OK, so what do we do with 7.3.1.  Increment major or minor?
> > 
> > Major.  I thought you did it already?
> 
> I did only minor, which I knew was safe.  Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1?  That
> seems very drastic, and there have been very few problem reports about
> the NOTIFY change.
-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting



Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Bruce Momjian writes:
> >> Do I need to increment the other interfaces that
> >> _use_ libpq, like ecpg?
> 
> > If and only if the libpq API is part of their documented API.  For ecpg I
> > think this is not the case, but for libpq++ it would seem to be the case.
> 
> However, an app linked against libpq++ would also be linked against
> libpq, and so the incompatibility will be flagged by the linker anyway.
> I can see no need to bump libpq++'s own number.

New question --- didn't we change the externally visible PGNotify
structure in libpq-fe.h in 7.3, and as returned by PQnotifies:
PGnotify *PQnotifies(PGconn *conn)

meaning if ecpg references PGnotify, should it have a new major number
too, so actually, we did change the API in 7.3 and not just the binary
compatibility.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> meaning if ecpg references PGnotify, should it have a new major number
> too,

No, because PGnotify is *not part of ecpg's API*.

The ecpg library, when compiled, will show a dependency on the new major
number for libpq.  That does not mean that applications linked to ecpg
need to be recompiled.  They don't (unless they depend directly on libpq
too).
        regards, tom lane


Re: PQnotifies() in 7.3 broken?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > meaning if ecpg references PGnotify, should it have a new major number
> > too,
> 
> No, because PGnotify is *not part of ecpg's API*.
> 
> The ecpg library, when compiled, will show a dependency on the new major
> number for libpq.  That does not mean that applications linked to ecpg
> need to be recompiled.  They don't (unless they depend directly on libpq
> too).

OK, got it.  That's the think I needed to understand.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Mon, Dec 16, 2002 at 11:01:00AM -0500, Bruce Momjian wrote:
> 
> New question --- didn't we change the externally visible PGNotify
> structure in libpq-fe.h in 7.3, and as returned by PQnotifies:

Speaking of which, what if user relies on sizeof(PGnotify::relname)?
That code will recompile without any problems, but it won't actually
work as expected.  So in a way, the change may require more than a
simple recompile.


Jeroen



Re: PQnotifies() in 7.3 broken?

From
"Jeroen T. Vermeulen"
Date:
On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote:
> 
> Speaking of which, what if user relies on sizeof(PGnotify::relname)?                                ^
             code
 


Jeroen



Re: PQnotifies() in 7.3 broken?

From
Lee Kindness
Date:
Jeroen T. Vermeulen writes:> On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote:> > Speaking of which,
whatif user relies on sizeof(PGnotify::relname)?>                                  ^>
code

Yes, a change in the size of relname makes this binary incompatible
and the user code changes may not be just a simple recompile - It all
depends on what it being used for!

Lee.