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.

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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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?)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)