Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
cannot run with 8.0's libpq. Example:

$ LD_LIBRARY_PATH=/home/peter/devel/pg80/pg-install/lib /home/peter/devel/pg74/pg-install/bin/psql --help
/home/peter/devel/pg74/pg-install/bin/psql: relocation error: /home/peter/devel/pg74/pg-install/bin/psql: undefined symbol:get_progname

I haven't looked further, but we have to fix this urgently, I think.

Search Discussions

  • Tom Lane at Feb 2, 2005 at 4:08 pm

    Peter Eisentraut writes:
    Martin Pitt has detected that the libpq API has changed incompatibly
    between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
    cannot run with 8.0's libpq.
    [ shrug... ] I don't think we've ever guaranteed that anyway. I will
    resist putting get_progname back into libpq, because it should never
    have been there, at least not with that name: it's an undocumented
    infringement on application namespace.

    regards, tom lane
  • Martin Pitt at Feb 2, 2005 at 4:54 pm
    Hi!

    (sorry for the additional addresses; I'm not subscribed to -hackers,
    so my mail will last a while until it arrives there).

    Tom Lane [2005-02-02 11:07 -0500]:
    Peter Eisentraut <peter_e@gmx.net> writes:
    Martin Pitt has detected that the libpq API has changed incompatibly
    between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
    cannot run with 8.0's libpq.
    [ shrug... ] I don't think we've ever guaranteed that anyway.
    If you don't guarantee a backwards compatible API, then you should
    give libpq a new SONAME. By keeping the SONAME "3" you did promise
    backwards compatibility.

    The problem with this issue is that it is a real pain for distributors
    to handle broken SONAMEs. If every distributor invents his own one,
    then there will be conflicts at some point. This gets worse if you do
    release a new libpq SONAME later, which might conflict with any fake
    SONAME a distributor might have invented.
    I will resist putting get_progname back into libpq, because it
    should never have been there, at least not with that name: it's an
    undocumented infringement on application namespace.
    I understand such concerns, but you cannot undo the history. libpq3
    is out there and installed on maybe hundreds of thousands of machines,
    and your own psql frontend uses it.

    The next best option would be to fix the 7.4 version of psql to not
    use this symbol any more. However, this is still a pain since then you
    cannot upgrade from earlier versions to 8.0 any more.

    What would you propose as a solution? There can only be one
    /usr/lib/libpq.so.3.

    Thanks,

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Tom Lane at Feb 2, 2005 at 5:02 pm

    Martin Pitt writes:
    What would you propose as a solution?
    Do nothing. The problem you are raising isn't very serious since
    RPM-style installations don't support concurrent installation of
    multiple PG versions anyway. That being the case, it doesn't really
    matter whether 8.0 psql can use a 7.4 library or vice versa.

    To do otherwise would essentially amount to deciding that get_progname
    is part of the exported API of libpq forevermore. That's not something
    I'm willing to buy into. It was a mistake that it was done that way in
    7.4, and I want to rectify that mistake before it gets any more
    entrenched.

    regards, tom lane
  • Peter Eisentraut at Feb 2, 2005 at 5:52 pm

    Tom Lane wrote:
    Martin Pitt <mpitt@debian.org> writes:
    What would you propose as a solution?
    Do nothing. The problem you are raising isn't very serious since
    RPM-style installations don't support concurrent installation of
    multiple PG versions anyway. That being the case, it doesn't really
    matter whether 8.0 psql can use a 7.4 library or vice versa.
    Partial upgrades is the key word.
    To do otherwise would essentially amount to deciding that
    get_progname is part of the exported API of libpq forevermore.
    That's not something I'm willing to buy into. It was a mistake that
    it was done that way in 7.4, and I want to rectify that mistake
    before it gets any more entrenched.
    We can rectify the mistake, but then we need to change the SONAME.
    That's what it's for.
  • Tom Lane at Feb 2, 2005 at 6:04 pm

    Peter Eisentraut writes:
    We can rectify the mistake, but then we need to change the SONAME.
    That's what it's for.
    Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.

    This brings up a point that I think has been discussed before: we
    operate on the assumption that incrementing SO_MINOR_VERSION is enough
    to distinguish different releases of libpq, but in point of fact it
    is not. The Linux conventions for library names, for one, essentially
    require us to bump SO_MAJOR_VERSION for every release if we want to have
    any hope of letting different versions coexist. Perhaps our convention
    should be to bump SO_MAJOR_VERSION for each of our major releases and
    only use SO_MINOR_VERSION when we change a library in a dot-release.

    regards, tom lane
  • Bruce Momjian at Feb 2, 2005 at 6:28 pm

    Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> writes:
    We can rectify the mistake, but then we need to change the SONAME.
    That's what it's for.
    Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.

    This brings up a point that I think has been discussed before: we
    operate on the assumption that incrementing SO_MINOR_VERSION is enough
    to distinguish different releases of libpq, but in point of fact it
    is not. The Linux conventions for library names, for one, essentially
    require us to bump SO_MAJOR_VERSION for every release if we want to have
    any hope of letting different versions coexist. Perhaps our convention
    should be to bump SO_MAJOR_VERSION for each of our major releases and
    only use SO_MINOR_VERSION when we change a library in a dot-release.
    According to our RELEASE_CHANGES documentation:

    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.

    so while I don't think we need to update the major number for every
    PostgreSQL major release, the removal of prog_name probably required a
    major bump.

    Oops.

    --
    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
  • Tom Lane at Feb 2, 2005 at 6:39 pm

    Bruce Momjian writes:
    According to our RELEASE_CHANGES documentation:
    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.
    so while I don't think we need to update the major number for every
    PostgreSQL major release, the removal of prog_name probably required a
    major bump.
    Well, the point is that get_progname *isn't* a "public" function.
    We never advertised it as a libpq entry point.

    What this really brings out to me is that our development process
    doesn't impose a very strong boundary between libpq and our bundled
    client programs. If the client programs were enforced to use only the
    documented public API of libpq then we'd not be having this discussion
    --- but stuff such as libpgport support functions tends to slip by under
    the radar. IIRC we've been bitten in exactly this way at least once
    before. What I'm suggesting is that we just solve the whole class of
    problems permanently, by abandoning the assumption that we're going to
    guarantee binary compatibility across major releases. I don't think
    that promise is really buying us anything very critical.

    If we don't go that way, then we need to have some automatic check that
    none of the client programs are using symbols they shouldn't be from
    libpq. (Hmm ... will the existence of the Windows port help here?)

    regards, tom lane
  • Bruce Momjian at Feb 2, 2005 at 6:50 pm

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    According to our RELEASE_CHANGES documentation:
    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.
    so while I don't think we need to update the major number for every
    PostgreSQL major release, the removal of prog_name probably required a
    major bump.
    Well, the point is that get_progname *isn't* a "public" function.
    We never advertised it as a libpq entry point.

    What this really brings out to me is that our development process
    doesn't impose a very strong boundary between libpq and our bundled
    client programs. If the client programs were enforced to use only the
    documented public API of libpq then we'd not be having this discussion
    --- but stuff such as libpgport support functions tends to slip by under
    the radar. IIRC we've been bitten in exactly this way at least once
    before. What I'm suggesting is that we just solve the whole class of
    problems permanently, by abandoning the assumption that we're going to
    guarantee binary compatibility across major releases. I don't think
    that promise is really buying us anything very critical.

    If we don't go that way, then we need to have some automatic check that
    none of the client programs are using symbols they shouldn't be from
    libpq. (Hmm ... will the existence of the Windows port help here?)
    Yes, I think Win32 will help as long as we don't let bad stuff get into
    libpqddll.def. The only downside I see to bumping the major number each
    time is that the major number could get pretty big. Do the dynamic
    library systems handle two-digit library version numbers properly?

    --
    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
  • Peter Eisentraut at Feb 2, 2005 at 7:32 pm

    Bruce Momjian wrote:
    The only downside I see to bumping the major
    number each time is that the major number could get pretty big. Do
    the dynamic library systems handle two-digit library version numbers
    properly?
    MySQL's client library is at 12, so I don't see a problem.
  • Peter Eisentraut at Feb 2, 2005 at 10:00 pm

    Tom Lane wrote:
    Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
    object.
    Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
    The Linux conventions for library names, for one,
    essentially require us to bump SO_MAJOR_VERSION for every release if
    we want to have any hope of letting different versions coexist.
    Perhaps our convention should be to bump SO_MAJOR_VERSION for each of
    our major releases and only use SO_MINOR_VERSION when we change a
    library in a dot-release.
    Well, the goal for coexistence is mainly the server and the
    server-dependent tools (pg_dump, psql, etc.). There is no per-se
    requirement to have libpq versions to coexist. If libpq has different
    sonames in different releases, then they would end up in differently
    named packages anyway (at least in Debian). If they don't have
    different sonames, then we declare that they are compatible, so it
    should be OK to have only the latest version installed. That requires
    us to stay honest with the sonames, but it does not require us to
    increase the sonames unnecessarily.
  • Bruce Momjian at Feb 2, 2005 at 11:46 pm

    Peter Eisentraut wrote:
    Tom Lane wrote:
    Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
    object.
    Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
    I am thinking we should up the 8.0.* and 8.1.* releases to have the same
    major number, but not make a major libpq bump for every major release
    unless it is required, like with prog_name. Is that the plan?

    I guess the big question is whether we would ever want a 7.2 psql or any
    other client to automatically use a 7.3 libpq. In fact by upping the
    major every time will 7.2 clients automatically use the 7.3 libpq or
    will they have to be relinked?

    --
    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 at Feb 3, 2005 at 3:25 am

    Bruce Momjian wrote:
    Peter Eisentraut wrote:
    Tom Lane wrote:
    Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
    object.
    Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
    I am thinking we should up the 8.0.* and 8.1.* releases to have the same
    major number, but not make a major libpq bump for every major release
    unless it is required, like with prog_name. Is that the plan?

    I guess the big question is whether we would ever want a 7.2 psql or any
    other client to automatically use a 7.3 libpq. In fact by upping the
    major every time will 7.2 clients automatically use the 7.3 libpq or
    will they have to be relinked?
    Uh, if we bump up the major library version in 8.0.X, will that require
    8.0.0 user applications to be recompiled? That seems worse than having
    7.4.X pg apps like psql fail. They fail because they are calling
    get_progname, but most user apps will not be calling that function.

    Also, if we bump the major version, will an install of 8.0.X fix
    problems with get_progname? Won't the 8.0.0 libpq with a higher minor
    version number still prevent old psql's from running? Our install
    doesn't uninstall old libraries, does it? RPM's might but I am not sure
    how they do minor upgrades.

    --
    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
  • Peter Eisentraut at Feb 3, 2005 at 6:59 am

    Bruce Momjian wrote:
    Uh, if we bump up the major library version in 8.0.X, will that
    require 8.0.0 user applications to be recompiled?
    No, they just keep using the old library.
  • Bruce Momjian at Feb 3, 2005 at 2:42 pm

    Peter Eisentraut wrote:
    Bruce Momjian wrote:
    Uh, if we bump up the major library version in 8.0.X, will that
    require 8.0.0 user applications to be recompiled?
    No, they just keep using the old library.
    That assumes the old libraries stay around. Will they?

    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.

    --
    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
  • Martin Pitt at Feb 3, 2005 at 3:58 pm
    Hi!

    Bruce Momjian [2005-02-03 9:42 -0500]:
    Peter Eisentraut wrote:
    Bruce Momjian wrote:
    Uh, if we bump up the major library version in 8.0.X, will that
    require 8.0.0 user applications to be recompiled?
    No, they just keep using the old library.
    That assumes the old libraries stay around. Will they?

    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.
    Seconded. Then we don't need another library version, and it is still
    not necessary to drag this get_progname accident forever.

    Thanks,

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Tom Lane at Feb 3, 2005 at 4:13 pm

    Martin Pitt writes:
    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.
    Seconded. Then we don't need another library version, and it is still
    not necessary to drag this get_progname accident forever.
    We're going to stop dragging the accident now, not a year from now.

    Putting get_progname back into libpq would require re-adding all of
    path.c, which creates many more issues than just adjusting
    SO_MAJOR_VERSION would do.

    regards, tom lane
  • Andrew Dunstan at Feb 3, 2005 at 4:25 pm

    Tom Lane wrote:
    Martin Pitt <mpitt@debian.org> writes:

    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.
    Seconded. Then we don't need another library version, and it is still
    not necessary to drag this get_progname accident forever.
    We're going to stop dragging the accident now, not a year from now.

    Putting get_progname back into libpq would require re-adding all of
    path.c, which creates many more issues than just adjusting
    SO_MAJOR_VERSION would do.


    Maybe I'm dense, but I don't understand why this is causing anyone a
    headache. Why would one install the 8.0 libs without the 8.0 clients?

    cheers

    andrew
  • Martin Pitt at Feb 3, 2005 at 4:43 pm
    Hi!

    Andrew Dunstan [2005-02-03 11:24 -0500]:
    Maybe I'm dense, but I don't understand why this is causing anyone a
    headache. Why would one install the 8.0 libs without the 8.0 clients?
    That's not the point. The point is that this breakage makes it
    impossible to install _both_ 7.4 and 8.0 server/client at the same
    time.

    In addition, this breaks partial upgrades: if the package libpq3 (as
    it is called in Debian) is upgraded from 7.4.x to 8.0.x (which is
    perfectly valid and does not break any dependencies, since it is the
    same library with the same API), but the postgresql-client package
    isn't (because it is on hold, or whatever), then this breaks the old
    postgresql-client as well.

    I'm fine with immediately bumping the SONAME too, but as I said, it's
    important that this happens upstream, not in the distributions.

    Thanks,

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Bruce Momjian at Feb 4, 2005 at 3:49 am
    Martin Pitt wrote:
    -- Start of PGP signed section.
    Hi!

    Andrew Dunstan [2005-02-03 11:24 -0500]:
    Maybe I'm dense, but I don't understand why this is causing anyone a
    headache. Why would one install the 8.0 libs without the 8.0 clients?
    That's not the point. The point is that this breakage makes it
    impossible to install _both_ 7.4 and 8.0 server/client at the same
    time.

    In addition, this breaks partial upgrades: if the package libpq3 (as
    it is called in Debian) is upgraded from 7.4.x to 8.0.x (which is
    perfectly valid and does not break any dependencies, since it is the
    same library with the same API), but the postgresql-client package
    isn't (because it is on hold, or whatever), then this breaks the old
    postgresql-client as well.

    I'm fine with immediately bumping the SONAME too, but as I said, it's
    important that this happens upstream, not in the distributions.
    Are users going to be happy to have to recompile all their user apps
    that use libpq because of a minor upgrade? We have required it in the
    past, 6.3.2:

    A dump/restore is NOT required for those running 6.3 or 6.3.1. A make
    distclean, make, and make install is all that is required. This last
    step should be performed while the postmaster is not running. You should
    re-link any custom applications that use PostgreSQL libraries.

    but in this case their apps are running fine and it is just old pg
    clients that need the fix.

    --
    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 at Feb 4, 2005 at 3:34 am

    Tom Lane wrote:
    Martin Pitt <mpitt@debian.org> writes:
    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.
    Seconded. Then we don't need another library version, and it is still
    not necessary to drag this get_progname accident forever.
    We're going to stop dragging the accident now, not a year from now.

    Putting get_progname back into libpq would require re-adding all of
    path.c, which creates many more issues than just adjusting
    SO_MAJOR_VERSION would do.
    Why can't we just put a copy of get_progname into libpq, rather than
    bring the entire file from libpgport?

    --
    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
  • Martin Pitt at Feb 7, 2005 at 7:05 pm
    Hi!

    Tom Lane [2005-02-03 11:12 -0500]:
    Martin Pitt <mpitt@debian.org> writes:
    I am thinking the easiest solution will be to re-add get_progname() to
    8.0.X and bump the major for 8.1.
    Seconded. Then we don't need another library version, and it is still
    not necessary to drag this get_progname accident forever.
    We're going to stop dragging the accident now, not a year from now.

    Putting get_progname back into libpq would require re-adding all of
    path.c, which creates many more issues than just adjusting
    SO_MAJOR_VERSION would do.
    The consensus seems to be to just bump the SONAME. The next one will
    definitively be "4" then? I would like to fix this in my packages
    before I announce them for public testing, but this issue is the only
    blocker to it.

    Will there be a new bugfix release soon?

    Thanks for your work and have a nice day!

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Peter Eisentraut at Feb 4, 2005 at 11:26 am

    Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
    Peter Eisentraut wrote:
    Bruce Momjian wrote:
    Uh, if we bump up the major library version in 8.0.X, will that
    require 8.0.0 user applications to be recompiled?
    No, they just keep using the old library.
    That assumes the old libraries stay around. Will they?
    Well, if someone did remove them then they didn't understand the point of the
    whole thing and should not be allowed to install libraries without
    supervision. :)
  • Bruce Momjian at Feb 4, 2005 at 2:33 pm

    Peter Eisentraut wrote:
    Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
    Peter Eisentraut wrote:
    Bruce Momjian wrote:
    Uh, if we bump up the major library version in 8.0.X, will that
    require 8.0.0 user applications to be recompiled?
    No, they just keep using the old library.
    That assumes the old libraries stay around. Will they?
    Well, if someone did remove them then they didn't understand the point of the
    whole thing and should not be allowed to install libraries without
    supervision. :)
    I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
    libpq will still see the 8.0.0 libpq and will still not work.

    That's why the get_progname() addition would be cleaner in some ways.

    --
    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
  • Tom Lane at Feb 4, 2005 at 3:27 pm

    Bruce Momjian writes:
    I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
    libpq will still see the 8.0.0 libpq and will still not work.
    That's why the get_progname() addition would be cleaner in some ways.
    How you figure that? Your first conclusion assumes that someone updates
    an 8.0.0 installation and fails to replace the 8.0.0 libpq, while your
    second conclusion assumes that they do replace the 8.0.0 libpq. This is
    unlikely in any package-based distribution (RPM doesn't forget such things)
    and if they built from source they have many other ways besides this to
    shoot themselves in the foot (like configuring SSL support one time and
    not the next).

    This problem isn't worth spending more development time on than it takes
    to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
    And it definitely isn't worth exposing the path.c symbols for a second
    release cycle and thereby doubling the odds that some outside code comes
    to depend on them ... in which case we'd *really* have a problem.

    regards, tom lane
  • Bruce Momjian at Feb 4, 2005 at 4:52 pm

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
    libpq will still see the 8.0.0 libpq and will still not work.
    That's why the get_progname() addition would be cleaner in some ways.
    How you figure that? Your first conclusion assumes that someone updates
    an 8.0.0 installation and fails to replace the 8.0.0 libpq, while your
    second conclusion assumes that they do replace the 8.0.0 libpq. This is
    unlikely in any package-based distribution (RPM doesn't forget such things)
    and if they built from source they have many other ways besides this to
    shoot themselves in the foot (like configuring SSL support one time and
    not the next).
    My point is that some will replace the 8.0.0 libpq (RPM), while others
    will not (source install), and that will lead to different failure
    cases.

    The first will lead to the requirement that all user applications be
    recompiled, and the later will lead to 7.4.X psql still not working.
    This problem isn't worth spending more development time on than it takes
    to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
    Those failure cases are worth addressing.
    And it definitely isn't worth exposing the path.c symbols for a second
    release cycle and thereby doubling the odds that some outside code comes
    to depend on them ... in which case we'd *really* have a problem.
    I suggested to just get_progname() to libpq, not all of path.c. The
    odds someone will depend on get_progname() in 8.0 are much less than the
    problems we will have as listed above.

    I like symbol cleanliness as much as the rest of you but I don't see a
    need to cause user problems to fix it in 8.0.X.

    --
    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
  • Peter Eisentraut at Feb 4, 2005 at 6:35 pm

    Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
    I suggested to just get_progname() to libpq, not all of path.c. The
    odds someone will depend on get_progname() in 8.0 are much less than the
    problems we will have as listed above.
    Perhaps a question is in order: Are we sure that get_progname() is the only
    problem, or just the first one the linker found? Does anyone remember?
  • Tom Lane at Feb 4, 2005 at 6:48 pm

    Peter Eisentraut writes:
    Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
    I suggested to just get_progname() to libpq, not all of path.c. The
    odds someone will depend on get_progname() in 8.0 are much less than the
    problems we will have as listed above.
    Perhaps a question is in order: Are we sure that get_progname() is the only
    problem, or just the first one the linker found? Does anyone remember?
    The report only showed that that one was the first the linker found.

    The 7.4 libpq does include path.c in its entirety, meaning that there
    are potentially dependencies out there for all of the symbols defined by
    7.4 path.c: is_absolute_path, first_path_separator, last_path_separator,
    in addition to get_progname. In the 8.0 version of path.c these symbols
    are intertwined with a bunch more; what's more, is_absolute_path is now
    a macro not a routine, so we lost ABI compatibility anyway. (I do in
    fact see is_absolute_path used in 7.4 psql; didn't bother looking for
    the others.)

    In short, fixing this the way Bruce wants to will be a nontrivial amount
    of effort.

    regards, tom lane
  • Bruce Momjian at Feb 4, 2005 at 9:33 pm

    Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> writes:
    Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
    I suggested to just get_progname() to libpq, not all of path.c. The
    odds someone will depend on get_progname() in 8.0 are much less than the
    problems we will have as listed above.
    Perhaps a question is in order: Are we sure that get_progname() is the only
    problem, or just the first one the linker found? Does anyone remember?
    The report only showed that that one was the first the linker found.

    The 7.4 libpq does include path.c in its entirety, meaning that there
    are potentially dependencies out there for all of the symbols defined by
    7.4 path.c: is_absolute_path, first_path_separator, last_path_separator,
    in addition to get_progname. In the 8.0 version of path.c these symbols
    are intertwined with a bunch more; what's more, is_absolute_path is now
    a macro not a routine, so we lost ABI compatibility anyway. (I do in
    fact see is_absolute_path used in 7.4 psql; didn't bother looking for
    the others.)

    In short, fixing this the way Bruce wants to will be a nontrivial amount
    of effort.
    psql actually calls get_progname(). Do we know that it will try to link
    in the other functions from path.c? I am unsure.

    --
    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
  • Tom Lane at Feb 4, 2005 at 9:42 pm

    Bruce Momjian writes:
    In short, fixing this the way Bruce wants to will be a nontrivial amount
    of effort.
    psql actually calls get_progname(). Do we know that it will try to link
    in the other functions from path.c? I am unsure.
    I don't know of any commonly used linkers that link at granularity finer
    than one source file, and in any case for shared libraries the library
    is all-or-nothing.

    Grep shows that 7.4 psql does reference is_absolute_path, and 7.4
    pg_dumpall does reference last_path_separator, so at least three of the
    four are at issue.

    regards, tom lane
  • Bruce Momjian at Feb 5, 2005 at 1:05 am

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    In short, fixing this the way Bruce wants to will be a nontrivial amount
    of effort.
    psql actually calls get_progname(). Do we know that it will try to link
    in the other functions from path.c? I am unsure.
    I don't know of any commonly used linkers that link at granularity finer
    than one source file, and in any case for shared libraries the library
    is all-or-nothing.

    Grep shows that 7.4 psql does reference is_absolute_path, and 7.4
    pg_dumpall does reference last_path_separator, so at least three of the
    four are at issue.
    Ewe, yep, that is a mess.

    OK, so how will we handle this? We will bump the major for 8.0.X.

    Do we also hack libpq/Makefile to remove the 8.0.0 libpq? If not, then
    RPM folks will need to relink, but source installs will not, but they
    will have to remove the 8.0.0 libpq if they also want to run 7.4.

    As you can see it is the confusion that bothers me. I am not sure how I
    would write a coherent paragraph explaining this.

    --
    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
  • Tom Lane at Feb 5, 2005 at 4:44 pm

    Bruce Momjian writes:
    As you can see it is the confusion that bothers me. I am not sure how I
    would write a coherent paragraph explaining this.
    The same thing you wrote the last time we had to do this (7.3.1).
    I don't recall any huge volume of complaints last time, so I think
    you're making a mountain out of a molehill.

    regards, tom lane
  • Bruce Momjian at Feb 5, 2005 at 11:52 pm

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    As you can see it is the confusion that bothers me. I am not sure how I
    would write a coherent paragraph explaining this.
    The same thing you wrote the last time we had to do this (7.3.1).
    I don't recall any huge volume of complaints last time, so I think
    you're making a mountain out of a molehill.
    OK, agreed.

    --
    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
  • Martin Pitt at Feb 7, 2005 at 7:56 pm
    Hi!

    Tom Lane [2005-02-04 10:27 -0500]:
    This problem isn't worth spending more development time on than it takes
    to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
    I just did that:

    --- postgresql-8.0.1-old/src/interfaces/libpq/Makefile 2005-01-26 20:24:19.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/Makefile 2005-02-07 20:09:38.719686432 +0100
    @@ -16,8 +16,8 @@

    # shared library parameters
    NAME= pq
    -SO_MAJOR_VERSION= 3
    -SO_MINOR_VERSION= 2
    +SO_MAJOR_VERSION= 4
    +SO_MINOR_VERSION= 0
    DLTYPE= library

    override CPPFLAGS := -DFRONTEND -I$(srcdir) $(CPPFLAGS) -I$(top_builddir)/src/port

    Is that right? Or will you use SO_MINOR_VERSION=1?

    However, I just stumbled across another problem: libpq3 and the new
    libpq4 use the same translation domain "libpq4", thus they cannot be
    installed in parallel. Can you please change the domain to "libpq4" as
    well? This should generally be done anyway, but at least we can live
    with one breakage of this rule (for libpq3), so that we don't need to
    mess with the old libpq3 package.

    Thanks,

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Bruce Momjian at Feb 9, 2005 at 11:05 pm
    Martin Pitt wrote:
    -- Start of PGP signed section.
    Hi!

    Tom Lane [2005-02-04 10:27 -0500]:
    This problem isn't worth spending more development time on than it takes
    to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
    I just did that:

    --- postgresql-8.0.1-old/src/interfaces/libpq/Makefile 2005-01-26 20:24:19.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/Makefile 2005-02-07 20:09:38.719686432 +0100
    @@ -16,8 +16,8 @@

    # shared library parameters
    NAME= pq
    -SO_MAJOR_VERSION= 3
    -SO_MINOR_VERSION= 2
    +SO_MAJOR_VERSION= 4
    +SO_MINOR_VERSION= 0
    DLTYPE= library

    override CPPFLAGS := -DFRONTEND -I$(srcdir) $(CPPFLAGS) -I$(top_builddir)/src/port

    Is that right? Or will you use SO_MINOR_VERSION=1?
    It would be zero. I wouldn't distribute this until we actually release
    it, but for testing I guess it is OK.
    However, I just stumbled across another problem: libpq3 and the new
    libpq4 use the same translation domain "libpq4", thus they cannot be
    installed in parallel. Can you please change the domain to "libpq4" as
    well? This should generally be done anyway, but at least we can live
    with one breakage of this rule (for libpq3), so that we don't need to
    mess with the old libpq3 package.
    Uh, what is the translation domain?

    --
    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
  • Martin Pitt at Feb 10, 2005 at 9:42 am
    Hi!

    Bruce Momjian [2005-02-09 18:05 -0500]:
    However, I just stumbled across another problem: libpq3 and the new
    libpq4 use the same translation domain "libpq4", thus they cannot be
    installed in parallel. Can you please change the domain to "libpq4" as
    well? This should generally be done anyway, but at least we can live
    with one breakage of this rule (for libpq3), so that we don't need to
    mess with the old libpq3 package.
    Uh, what is the translation domain?
    In short, that is the unique name for a bunch of translations for a
    particular application or group of related applications. The key point
    is that the name of the file in
    /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call

    bindtextdomain ("<DOMAIN>", NULL)

    must use the same <DOMAIN> so that libintl can find the mo file.
    However, that means that all applications that are installed in
    parallel need a distinct domain. Since the whole point of SONAMes is
    to allow several different library API versions to be installed in
    parallel, every library API (i. e. SONAME) should have an unique
    domain, which can be achieved easiest by just appending the SONAME to
    the translation domain.

    In my test packages I used the following patch:

    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
    --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
    @@ -1133,7 +1133,7 @@
    {
    already_bound = 1;
    /* No relocatable lookup here because the binary could be anywhere */
    - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    }

    return dgettext("libpq", msgid);
    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
    --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk 2005-01-14 09:57:06.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk 2005-02-07 22:54:54.770217616 +0100
    @@ -1,5 +1,5 @@
    # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
    -CATALOG_NAME := libpq
    +CATALOG_NAME := libpq4
    AVAIL_LANGUAGES := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
    GETTEXT_FILES := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
    GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2

    Compared to the SONAME, changing the translation domain is relatively
    uncritical, so if you don't want to change this upstream, I can
    maintain this patch for Debian/Ubuntu. However, I heard that some RPM
    guys plan a infrastructure similar to mine, and at that point they
    will have precisely the same problems :-)

    Thanks for considering and have a nice day!

    Martin
    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Bruce Momjian at Feb 10, 2005 at 5:16 pm
    Martin Pitt wrote:
    -- Start of PGP signed section.
    Hi!

    Bruce Momjian [2005-02-09 18:05 -0500]:
    However, I just stumbled across another problem: libpq3 and the new
    libpq4 use the same translation domain "libpq4", thus they cannot be
    installed in parallel. Can you please change the domain to "libpq4" as
    well? This should generally be done anyway, but at least we can live
    with one breakage of this rule (for libpq3), so that we don't need to
    mess with the old libpq3 package.
    Uh, what is the translation domain?
    In short, that is the unique name for a bunch of translations for a
    particular application or group of related applications. The key point
    is that the name of the file in
    /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call

    bindtextdomain ("<DOMAIN>", NULL)
    Well, that is certainly interesting.
    must use the same <DOMAIN> so that libintl can find the mo file.
    However, that means that all applications that are installed in
    parallel need a distinct domain. Since the whole point of SONAMes is
    to allow several different library API versions to be installed in
    parallel, every library API (i. e. SONAME) should have an unique
    domain, which can be achieved easiest by just appending the SONAME to
    the translation domain.
    I see. So we have to auto-populate the SONAME into all those places.
    Now that you mention it, it makes sense because the language strings are
    fixed for every major release so I can see the need for this when using
    two major versions of PostgreSQL.

    ---------------------------------------------------------------------------
    In my test packages I used the following patch:

    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
    --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
    @@ -1133,7 +1133,7 @@
    {
    already_bound = 1;
    /* No relocatable lookup here because the binary could be anywhere */
    - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    }

    return dgettext("libpq", msgid);
    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
    --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk 2005-01-14 09:57:06.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk 2005-02-07 22:54:54.770217616 +0100
    @@ -1,5 +1,5 @@
    # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
    -CATALOG_NAME := libpq
    +CATALOG_NAME := libpq4
    AVAIL_LANGUAGES := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
    GETTEXT_FILES := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
    GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2

    Compared to the SONAME, changing the translation domain is relatively
    uncritical, so if you don't want to change this upstream, I can
    maintain this patch for Debian/Ubuntu. However, I heard that some RPM
    guys plan a infrastructure similar to mine, and at that point they
    will have precisely the same problems :-)

    Thanks for considering and have a nice day!

    Martin
    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
    -- End of PGP section, PGP failed!

    --
    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 at Jun 7, 2005 at 1:23 am
    Is this a direction we want to explore --- using the SONAME as part of
    the translation domain?

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

    Martin Pitt wrote:
    -- Start of PGP signed section.
    Hi!

    Bruce Momjian [2005-02-09 18:05 -0500]:
    However, I just stumbled across another problem: libpq3 and the new
    libpq4 use the same translation domain "libpq4", thus they cannot be
    installed in parallel. Can you please change the domain to "libpq4" as
    well? This should generally be done anyway, but at least we can live
    with one breakage of this rule (for libpq3), so that we don't need to
    mess with the old libpq3 package.
    Uh, what is the translation domain?
    In short, that is the unique name for a bunch of translations for a
    particular application or group of related applications. The key point
    is that the name of the file in
    /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call

    bindtextdomain ("<DOMAIN>", NULL)

    must use the same <DOMAIN> so that libintl can find the mo file.
    However, that means that all applications that are installed in
    parallel need a distinct domain. Since the whole point of SONAMes is
    to allow several different library API versions to be installed in
    parallel, every library API (i. e. SONAME) should have an unique
    domain, which can be achieved easiest by just appending the SONAME to
    the translation domain.

    In my test packages I used the following patch:

    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
    --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
    @@ -1133,7 +1133,7 @@
    {
    already_bound = 1;
    /* No relocatable lookup here because the binary could be anywhere */
    - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    }

    return dgettext("libpq", msgid);
    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
    --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk 2005-01-14 09:57:06.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk 2005-02-07 22:54:54.770217616 +0100
    @@ -1,5 +1,5 @@
    # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
    -CATALOG_NAME := libpq
    +CATALOG_NAME := libpq4
    AVAIL_LANGUAGES := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
    GETTEXT_FILES := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
    GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2

    Compared to the SONAME, changing the translation domain is relatively
    uncritical, so if you don't want to change this upstream, I can
    maintain this patch for Debian/Ubuntu. However, I heard that some RPM
    guys plan a infrastructure similar to mine, and at that point they
    will have precisely the same problems :-)

    Thanks for considering and have a nice day!

    Martin
    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
    -- End of PGP section, PGP failed!

    --
    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
  • Alvaro Herrera at Jun 7, 2005 at 4:42 am

    On Mon, Jun 06, 2005 at 09:23:21PM -0400, Bruce Momjian wrote:

    Is this a direction we want to explore --- using the SONAME as part of
    the translation domain?
    Hm, interesting -- this could explain some weird problems I've had with
    translated text on a machine where multiple versions are installed.
    I'll investigate a bit and if it turns out to be solved by this
    approach, it has my vote.

    However I think we should stay away from using the version number as a
    string inside the source. If we do tht, we will forget to increment it
    in the future and we will have problems.
    In my test packages I used the following patch:

    diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
    --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
    +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
    @@ -1133,7 +1133,7 @@
    {
    already_bound = 1;
    /* No relocatable lookup here because the binary could be anywhere */
    - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
    }
    --
    Alvaro Herrera (<alvherre[a]surnet.cl>)
    "La experiencia nos dice que el hombre peló millones de veces las patatas,
    pero era forzoso admitir la posibilidad de que en un caso entre millones,
    las patatas pelarían al hombre" (Ijon Tichy)
  • Martin Pitt at Jun 7, 2005 at 7:16 am
    Hi!

    Bruce Momjian [2005-06-06 21:23 -0400]:
    Is this a direction we want to explore --- using the SONAME as part of
    the translation domain?
    If that would go upstream, so much the better. I already do it in the
    Debian and Ubuntu packages since I don't have any choice anyway, and
    it's not really hard to maintain. But if it would go upstream, other
    vendors might benefit from that as well.

    However, as Alvaro already said, the patch should probably be refined
    to take the SONAME from the Makefile somehow instead of hardcoding it.

    Thanks and have a nice day!

    Martin

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian Developer http://www.debian.org
  • Peter Eisentraut at Jun 7, 2005 at 6:34 pm

    Bruce Momjian wrote:
    Is this a direction we want to explore --- using the SONAME as part
    of the translation domain?
    I think that's the way to go.
  • Greg Stark at Feb 3, 2005 at 3:43 am

    Bruce Momjian writes:

    In fact by upping the major every time will 7.2 clients automatically use
    the 7.3 libpq or will they have to be relinked?
    If you do not bump the soname then 7.2 clients will automatically immediately
    start using the new library when it's installed. (actually when ldconfig is
    run, which distributions will normally do automatically).

    If you do bump the versions then 7.2 clients will continue to use 7.2
    libraries. If you have 7.2 clients, or even clients like DBD::Pg or other
    third-party libpq apps then you would have to relink them to use the new
    libraries. But you would probably just keep around both sets of libraries.

    I could see valid arguments for either when it comes to whether to bump it
    when it's not strictly necessary.

    If libpq were used by lots of external applications using the public interface
    then bumping it more than necessary means people have to keep around extra
    versions for no reason.

    On the other hand if libpq is seen as an integral part of the postgres package
    and its specific behaviour is important then not bumping the version forces
    admins to pick one version for everything when they might prefer that 7.2
    clients stick with the 7.2 library.

    In a way the fact that you release new libpq versions when you release
    security releases for old releases like 7.3 or 7.4 sort of already implies an
    answer. If you thought the new library was plug-in compatible and should
    completely replace the old library automatically you wouldn't continue to
    release modified versions of the old library, you would just release HEAD for
    libpq all the time.

    --
    greg
  • Tom Lane at Feb 2, 2005 at 11:53 pm

    Peter Eisentraut writes:
    ... If they don't have
    different sonames, then we declare that they are compatible, so it
    should be OK to have only the latest version installed. That requires
    us to stay honest with the sonames, but it does not require us to
    increase the sonames unnecessarily.
    Well, the problem I'm concerned about is how do we stay honest. We now
    realize that our devel procedures may not catch this sort of mistake.

    It might be that the Windows DLLs will catch any unintentional
    dependencies, but I'm not feeling especially comfortable about it.

    regards, tom lane
  • Bruce Momjian at Feb 3, 2005 at 3:16 am

    Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> writes:
    ... If they don't have
    different sonames, then we declare that they are compatible, so it
    should be OK to have only the latest version installed. That requires
    us to stay honest with the sonames, but it does not require us to
    increase the sonames unnecessarily.
    Well, the problem I'm concerned about is how do we stay honest. We now
    realize that our devel procedures may not catch this sort of mistake.

    It might be that the Windows DLLs will catch any unintentional
    dependencies, but I'm not feeling especially comfortable about it.
    I am hopefull Win32 will help here and am willing to give it another
    try.

    --
    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
  • Martin Pitt at Feb 2, 2005 at 8:42 pm
    Hi Tom!

    Tom Lane [2005-02-02 12:01 -0500]:
    Martin Pitt <mpitt@debian.org> writes:
    What would you propose as a solution?
    Do nothing.
    That's unfortunately not an option.
    The problem you are raising isn't very serious since
    RPM-style installations don't support concurrent installation of
    multiple PG versions anyway. That being the case, it doesn't really
    matter whether 8.0 psql can use a 7.4 library or vice versa.
    That's exactly the point I want to change for Debian, I work on a
    structure which permits to run several clusters of different versions
    in parallel (see [1]). We now have a /usr/lib/libpq.so.3 for 7.4, and
    we can't have a _second_ incompatible /usr/lib/libpq.so.3 for 8.0.

    Sorry, but that's just the way how shared libraries work. SONAMEs are
    for API compatibility and it becomes _very_ hard to workaround broken
    ones.
    To do otherwise would essentially amount to deciding that get_progname
    is part of the exported API of libpq forevermore.
    That's not true. It must stay part of the exported API for SONAME 3 of
    libpq, not for anything else.
    That's not something I'm willing to buy into. It was a mistake that
    it was done that way in 7.4, and I want to rectify that mistake
    before it gets any more entrenched.
    Then please release 8.0.2 with a SONAME 4. Would you consider this?

    Thanks a lot and have a nice day!

    Martin

    [1] http://people.debian.org/~mpitt/postgresql-ng.html

    --
    Martin Pitt http://www.piware.de
    Ubuntu Developer http://www.ubuntulinux.org
    Debian GNU/Linux Developer http://www.debian.org
  • Magnus Hagander at Feb 2, 2005 at 10:21 pm

    According to our RELEASE_CHANGES documentation:
    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.
    so while I don't think we need to update the major number for every
    PostgreSQL major release, the removal of prog_name probably
    required a
    major bump.
    Well, the point is that get_progname *isn't* a "public" function.
    We never advertised it as a libpq entry point.

    What this really brings out to me is that our development
    process doesn't impose a very strong boundary between libpq
    and our bundled client programs. If the client programs were
    enforced to use only the documented public API of libpq then
    we'd not be having this discussion
    --- but stuff such as libpgport support functions tends to
    slip by under the radar. IIRC we've been bitten in exactly
    this way at least once before. What I'm suggesting is that
    we just solve the whole class of problems permanently, by
    abandoning the assumption that we're going to guarantee
    binary compatibility across major releases. I don't think
    that promise is really buying us anything very critical.

    If we don't go that way, then we need to have some automatic
    check that none of the client programs are using symbols they
    shouldn't be from libpq. (Hmm ... will the existence of the
    Windows port help here?)
    Yes, it will. At least it will refuse to link with references that are
    not in the libpqdll.def file. It won't change if the *signature* of the
    functions change.

    <flashback
    href="http://archives.postgresql.org/pgsql-hackers-win32/2004-10/msg0004
    2.php"> ;-) + thread.

    //Magnus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 2, '05 at 1:53p
activeJun 7, '05 at 6:34p
posts46
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase