Re: PQnotifies() in 7.3 broken?

OK, so what do we do with 7.3.1. Increment major or minor?

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

pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(dot)Elphick(at)lfix(dot)co(dot)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

Oliver Elphick wrote:
> On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)lfix(dot)co(dot)uk>
LFIX Limited

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

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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)sysexperts(dot)com

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(at)lfix(dot)co(dot)uk>
> LFIX Limited
>
>

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

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(at)lfix(dot)co(dot)uk>
> LFIX Limited
>
>

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

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
libpq.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(dot)Elphick(at)lfix(dot)co(dot)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

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(at)sysexperts(dot)com

Peter Eisentraut <peter_e(at)gmx(dot)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

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(at)gmx(dot)net

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

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(at)candle(dot)pha(dot)pa(dot)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(at)copelandconsulting(dot)net>
Copeland Computer Consulting

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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

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 binary incompatible
and the user code changes may not be just a simple recompile - It all
depends on what it being used for!

Lee.