Jeroen T. Vermeulen writes:
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
Yes, a change in the size of relname makes this
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
---(end of broadcast)---
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
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 [EMAIL PROTECTED]
Peter Eisentraut [EMAIL PROTECTED] 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.
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
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 [EMAIL PROTECTED] writes:
OK, so what do we do with 7.3.1. Increment major or minor?
Major. I
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
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
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.so
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.
On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
Oliver Elphick wrote:
On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
Jeroen T. Vermeulen wrote:
On Fri, Dec 13, 2002 at 09:06:47PM +, 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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
OK, so what do we do with 7.3.1. Increment major or minor?
---
pgman wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wrong --- if you need a recompile then it's not
Bruce Momjian [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 5: Have you checked our extensive
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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?
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
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
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
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
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|
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
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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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.
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
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
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] 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
Lee Kindness wrote:
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] 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
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: [EMAIL PROTECTED]
2323 Yonge Street,
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
Bruce Momjian [EMAIL PROTECTED] 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
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:
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.
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
Jeroen T. Vermeulen [EMAIL PROTECTED] 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
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
Lee Kindness [EMAIL PROTECTED] 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?
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6:
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
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
59 matches
Mail list logo
