latest version?

Pawel Wegrzyn wrote:

Hi,
What is the latest version of PostgreSQL?
Is there something like 7.1?

The most recent version 7.0.2. 7.1 is about to come - I am looking
forward to it as well.

Regards,
Mit freundlichem Gru�,
Holger Klawitter
--
Holger Klawitter +49 (0)251 484 0637
holger@klawitter.de http://www.klawitter.de/

On Wed, 25 Oct 2000, Holger Klawitter wrote:

Pawel Wegrzyn wrote:

Hi,
What is the latest version of PostgreSQL?
Is there something like 7.1?

The most recent version 7.0.2. 7.1 is about to come - I am looking
forward to it as well.

7.0.3 is about to come out, 7.1 is about 2 months away yet :)

The Hermit Hacker <scrappy@hub.org> writes:

On Wed, 25 Oct 2000, Holger Klawitter wrote:

Pawel Wegrzyn wrote:

Hi,
What is the latest version of PostgreSQL?
Is there something like 7.1?

The most recent version 7.0.2. 7.1 is about to come - I am looking
forward to it as well.

7.0.3 is about to come out, 7.1 is about 2 months away yet :)

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

The reason I'm asking is that Red Hat wants to maintain binary
compatibility in a for all x in y.x (that's what distribution
numbering means to us, other Linux distributions have other (and
sometimes rather weird) schemes), but I'm also interested in upgrading
the database component.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

[ Charset ISO-8859-1 unsupported, converting... ]

The Hermit Hacker <scrappy@hub.org> writes:

On Wed, 25 Oct 2000, Holger Klawitter wrote:

Pawel Wegrzyn wrote:

Hi,
What is the latest version of PostgreSQL?
Is there something like 7.1?

The most recent version 7.0.2. 7.1 is about to come - I am looking
forward to it as well.

7.0.3 is about to come out, 7.1 is about 2 months away yet :)

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

Historically, all applications have been able to talk to newer servers,
so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients
can talk to 7.1 postmasters.

We usually do not go the other way, where 6.5 clients can not talk to
6.4 postmasters. I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

Trond Eivind Glomsr�d wrote:

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

Historically, all applications have been able to talk to newer servers,
so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients
can talk to 7.1 postmasters.

We usually do not go the other way, where 6.5 clients can not talk to
6.4 postmasters. I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

He's meaning the libpq version for dynamic link loading. Is the
libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
compatibility for other RPM's linked against libpq.so.2.0, which failed
when libpq.so.2.1 came on the scene). I think the answer is no, but I
haven't checked the details yet.

Not just libpq, though -- libpgtcl.so has also been problematic.

Of course, the file format on disk changes (again!), which is a whole
'nother issue for RPM's......
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

This should work as far as simple connectivity goes, but 7.0
applications that do queries against system catalogs might find
that their queries need to be updated. For example, psql's backslash
commands didn't recognize views for awhile due to pg_class.relkind
changes.

regards, tom lane

[ Charset ISO-8859-1 unsupported, converting... ]

Bruce Momjian wrote:

Trond Eivind Glomsr?d wrote:

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

Historically, all applications have been able to talk to newer servers,
so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients
can talk to 7.1 postmasters.

We usually do not go the other way, where 6.5 clients can not talk to
6.4 postmasters. I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

He's meaning the libpq version for dynamic link loading. Is the
libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
compatibility for other RPM's linked against libpq.so.2.0, which failed
when libpq.so.2.1 came on the scene). I think the answer is no, but I
haven't checked the details yet.

I usually up the .so version numbers before entering beta. That way,
they get marked as newer than older versions.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

[Taken off GENERAL, added HACKERS to cc:]

Bruce Momjian wrote:

He's meaning the libpq version for dynamic link loading. Is the
libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
compatibility for other RPM's linked against libpq.so.2.0, which failed
when libpq.so.2.1 came on the scene). I think the answer is no, but I
haven't checked the details yet.

I usually up the .so version numbers before entering beta. That way,
they get marked as newer than older versions.

May I ask: is it necessary? Have there been version-bumping changes to
libpq since 7.0.x? (With the rate that necessary improvement is
happening to PostgreSQL, probably).

Let me explain:
RPM's contain a plethora of dependency information, some of which is
added manually, but most of which is generated automatically. These
dependencies are based on which 'soname' is needed to satisfy dynamic
linking requirements, interpreter requirements, etc. With version
numbers as part of the name, a change in version numbers changes the
dependency.
Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

Now, that doesn't directly effect the PostgreSQL RPM's. What it does
effect is the guy who wants to install PHP from with PostgreSQL support
enabled and cannot because of a failed dependency. Who gets blamed?
PostgreSQL.

Trond may correct me on this, but I don't know of a workaround for
this. And any workaround has to be applied to packages that depend upon
PostgreSQL, not to the PostgreSQL RPM's (which I would gladly modify) --
although I am going to try something -- I know that a symlink to the old
soname works, even though it is a kludge and, IMO, stinks like a
polecat.

But, enough rant. That _is_ I believe what Trond was asking about. We
have been bitten before with people installing the PHP from RedHat 6.2
after installing the PostgreSQL 7.0.x RPMset -- and dependency failures
wreaked havoc.

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

Actually, Bruce, it would do me and Trond a great favor if a list of
what so's are getting bumped and to what version were to be posted. At
least we can plan for a transition at that point.

I just hate to pull a threepeat on RedHat customers. (RH 5.0 shipped PG
6.2.1. RH 5.1 shipped PG 6.3.2. BONG!) (RH 6.0 shipped 6.4.2 (bong!) RH
6.1 shipped 6.5.2 (double BONG!)). RH 7 shipped 7.0.x (small bong) --
RH 7.1 ships 7.1.x (ouch bong).

Whew. Trond, you ready for this?

[Note: I have been ill, so this message may be more incoherent than my
normal scattered self]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

[ Blind CC to general added for comment below.]

[Taken off GENERAL, added HACKERS to cc:]

Bruce Momjian wrote:

He's meaning the libpq version for dynamic link loading. Is the
libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
compatibility for other RPM's linked against libpq.so.2.0, which failed
when libpq.so.2.1 came on the scene). I think the answer is no, but I
haven't checked the details yet.

I usually up the .so version numbers before entering beta. That way,
they get marked as newer than older versions.

May I ask: is it necessary? Have there been version-bumping changes to
libpq since 7.0.x? (With the rate that necessary improvement is
happening to PostgreSQL, probably).

No, only major releases have bumps.

But, enough rant. That _is_ I believe what Trond was asking about. We
have been bitten before with people installing the PHP from RedHat 6.2
after installing the PostgreSQL 7.0.x RPMset -- and dependency failures
wreaked havoc.

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

Actually, Bruce, it would do me and Trond a great favor if a list of
what so's are getting bumped and to what version were to be posted. At
least we can plan for a transition at that point.

See pgsql/src/tools/RELEASE_CHANGES. I edit interfaces/*/Makefile and
increase the minor number for every interface by one.

Let me add one thing on this RPM issue. There has been a lot of talk
recently about RPM's, and what they should do, and what they don't do,
and who should be blamed. Unfortunately, much of the discussion has
been very unproductive and more like 'venting'.

I really don't appreciate people 'venting' on these lists, especially
since we have _nothing_ to do with RPM's. All we do is make the
PostgreSQL software.

If people want to discuss RPM's on the ports list, or want to create a
new list just about RPM's, that's OK, but venting is bad, and venting on
a list that has nothing to do with RPM's is even worse.

What would be good is for someone to constructively make a posting about
the known problems, and come up with acceptible solutions. Asking us to
fix it really isn't going to help because we don't deal with RPM's here,
and we don't have enough free time to make significant changes to meet
the needs of RPM's.

Also, remember we support many Unix platforms, and Linux is only one of
them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Lamar Owen <lamar.owen@wgcr.org> writes:

Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

If so, I claim RPM is broken.

The whole point of major/minor version numbering for .so's is that
a minor version bump is supposed to be binary-upward-compatible.
If the RPM stuff has arbitrarily decided that it won't honor that
definition, why do we bother with multiple numbers at all?

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

To answer your question, there are no pending changes in libpq that
would mandate a major version bump (ie, nothing binary-incompatible,
AFAIK). We could ship it with the exact same version number, but then
how are people to tell whether they have a 7.0 or 7.1 libpq?

regards, tom lane

Lamar Owen <lamar.owen@wgcr.org> writes:

Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

If so, I claim RPM is broken.

The whole point of major/minor version numbering for .so's is that
a minor version bump is supposed to be binary-upward-compatible.
If the RPM stuff has arbitrarily decided that it won't honor that
definition, why do we bother with multiple numbers at all?

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

To answer your question, there are no pending changes in libpq that
would mandate a major version bump (ie, nothing binary-incompatible,
AFAIK). We could ship it with the exact same version number, but then
how are people to tell whether they have a 7.0 or 7.1 libpq?

Yes, we need to have new numbers so binaries from different releases use
the proper .so files.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

Lamar Owen wrote:

May I ask: is it necessary? Have there been version-bumping changes to
libpq since 7.0.x? (With the rate that necessary improvement is
happening to PostgreSQL, probably).

No, only major releases have bumps.

See pgsql/src/tools/RELEASE_CHANGES. I edit interfaces/*/Makefile and
increase the minor number for every interface by one.

Thanks for the pointer.

Let me add one thing on this RPM issue. There has been a lot of talk
recently about RPM's, and what they should do, and what they don't do,
and who should be blamed. Unfortunately, much of the discussion has
been very unproductive and more like 'venting'.

I really don't appreciate people 'venting' on these lists, especially
since we have _nothing_ to do with RPM's. All we do is make the
PostgreSQL software.

What would be good is for someone to constructively make a posting about
the known problems, and come up with acceptible solutions. Asking us to
fix it really isn't going to help because we don't deal with RPM's here,
and we don't have enough free time to make significant changes to meet
the needs of RPM's.

Which is why I stepped up to the plate last year to help with RPM's.

I apologize if you took my post (which I edited greatly) as 'venting' --
it was not my intention to 'vent', much less offend. I just want to
know what to expect from the 7.1 release. I feel that that is germane
to the Hackers list, as the knowledge necessary to answer the question
is to be found on the list. (and you answered the question above).

Like it or not, in the eyes of many people having solid RPM's is a core
issue. If there are gotchas, I want to document them so people don't
get blindsided. Or work around them. Or ask why the change is
necessary in the first place.

I appreciate the fact that we are not here to make it easy for
distributors to package our software. I also appreciate the fact that
if you don't at least make an effort to work with major distributors
(and RedHat, TurboLinux, Caldera, and SuSE together comprise a major
userbase) that you run the risk of not being distributed in favor of an
inferior product.

I also appreciate and applaud the cross-platform mentality of the
PostgreSQL developers. Linux is far from the only OS to be supported by
PostgreSQL, true. But Linux is also the most popular OS for PostgreSQL
deployment.

However, there are known problems that can bite people who are not using
RPM's and are not running Linux. Some of those problems are such that
it will take someone with more knowledge than I currently possess to
solve. One is the issue of upgrading/migrating tools. This is not an
RPM-specific issue. To me, that is the only big issue that I have
spoken about in a way that could even remotely be construed as
'venting'. And it is not a Linux-specific issue. It is a core issue.

I'll shut up now, as I have cross-distribution RPM problems to solve.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

What would be good is for someone to constructively make a posting about
the known problems, and come up with acceptable solutions. Asking us to
fix it really isn't going to help because we don't deal with RPM's here,
and we don't have enough free time to make significant changes to meet
the needs of RPM's.

Which is why I stepped up to the plate last year to help with RPM's.

I apologize if you took my post (which I edited greatly) as 'venting' --
it was not my intention to 'vent', much less offend. I just want to
know what to expect from the 7.1 release. I feel that that is germane
to the Hackers list, as the knowledge necessary to answer the question
is to be found on the list. (and you answered the question above).

No, I was not pointing to you when I mentioned venting. There have been
other RPM threads lately. I just want information on how to make things
better for RPM's, not vents.

Like it or not, in the eyes of many people having solid RPM's is a core
issue. If there are gotchas, I want to document them so people don't
get blindsided. Or work around them. Or ask why the change is
necessary in the first place.

Sure.

I appreciate the fact that we are not here to make it easy for
distributors to package our software. I also appreciate the fact that
if you don't at least make an effort to work with major distributors
(and RedHat, TurboLinux, Caldera, and SuSE together comprise a major
userbase) that you run the risk of not being distributed in favor of an
inferior product.

Let them. It is their decision. Frankly, I have seen this attitude
before, and I don't like it. Just the mention that "Gee, if you don't
cooperate, we may yank you," is really a veiled threat. Now, I know you
aren't saying that, but the "if you don't play nice, we will drop you"
argument sounds a lot more like MS that a Linux vendor should be acting,
especially since they are not telling us what they want or assisting in
the work.

The "We are big. Just fix it and let us know when it is ready" attitude
does not work here, and that is what I am hearing mostly from the RPM
people.

I also appreciate and applaud the cross-platform mentality of the
PostgreSQL developers. Linux is far from the only OS to be supported by
PostgreSQL, true. But Linux is also the most popular OS for PostgreSQL
deployment.

True, it is the most popular, but that doesn't make the others less
important.

This whole statement comes across as, "You run on Linux, and look, you
took the time to run on other OS's too. How quaint."

In the history of this project, Linux was an after-thought. None of our
platforms are inferior or superior, except to the extent that the
platform does not support Unix standard functions (like NT/Cygwin).

However, there are known problems that can bite people who are not using
RPM's and are not running Linux. Some of those problems are such that
it will take someone with more knowledge than I currently possess to
solve. One is the issue of upgrading/migrating tools. This is not an
RPM-specific issue. To me, that is the only big issue that I have
spoken about in a way that could even remotely be construed as
'venting'. And it is not a Linux-specific issue. It is a core issue.

Again, your comments where quite helpful. We need more of them. We
need to hear more about the problems people are having with RPM's, and
how to make them better.

There must be a list of known problems. Let's hear them, so we can try
to solve them as a group. However, in general, we do not make dramatic
change to work around OS bugs, and do not plan to make major changes to
work around the limitations of RPM's. My bet is that some middle layer
can be created that will fix that for us.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Let them. It is their decision. Frankly, I have seen this attitude
before, and I don't like it. Just the mention that "Gee, if you don't
cooperate, we may yank you," is really a veiled threat. Now, I know you
aren't saying that, but the "if you don't play nice, we will drop you"
argument sounds a lot more like MS that a Linux vendor should be acting,
especially since they are not telling us what they want or assisting in
the work.

FWIW, I've never threatened to do so. If I wanted to, I would just do
it[1]which I'm not even close to doing - I've spent a bit of time lately hunting down aliasing bugs in MySQL which causes wrong SQL query results if compiled with "-O2". Ouch. -- Trond Eivind Glomsr�d Red Hat, Inc. - threats are bad and never cause anything but bad feelings.

That being said, my favorite wishes (in addition to as much SQL
compliance and performance as possible, of course) are:

* migration on upgrade
* old libraries being able to speak to newer databases, so old
binaries can continue working after database upgrades
* good sonames on libraries - if a library hasn't changed, bumping the
number to show it's part of a new version isn't necesarry. If it is
backwards compatible, just bump the minor version, if it isn't, bump
the major version. Or even better, use versioned symbols (I don't
know how many other OSes than Linux and Solaris supports this,
though).

As for assisting, at least Red Hat contributes to a lot of projects,
some of which are important to postgres on one or more platforms: gdb,
gcc, glibc and the linux kernel. There just isn't enough resources to
do everything, but I try to help out with the RPMs.

When we make patches for packages, we try to cooperate with the
author(s) to get them in - happily, we haven't had much of a need for
that with postgresql.

The "We are big. Just fix it and let us know when it is ready" attitude
does not work here, and that is what I am hearing mostly from the RPM
people.

I haven't heard anyone say that.

There must be a list of known problems. Let's hear them, so we can try
to solve them as a group. However, in general, we do not make dramatic
change to work around OS bugs, and do not plan to make major changes to
work around the limitations of RPM's.

I don't think there are any apart from the upgrade issues - if library
versioning follows the standard, that certainly won't be a problem.

[1]: which I'm not even close to doing - I've spent a bit of time lately hunting down aliasing bugs in MySQL which causes wrong SQL query results if compiled with "-O2". Ouch. -- Trond Eivind Glomsr�d Red Hat, Inc.
hunting down aliasing bugs in MySQL which causes wrong SQL query
results if compiled with "-O2". Ouch.
--
Trond Eivind Glomsr�d
Red Hat, Inc.

Tom Lane <tgl@sss.pgh.pa.us> writes:

Lamar Owen <lamar.owen@wgcr.org> writes:

Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

You link against libpq.so.2 , not libpq.so.2.1. This isn't a problem.

If the RPM stuff has arbitrarily decided that it won't honor that
definition, why do we bother with multiple numbers at all?

There is no such problem.

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

To answer your question, there are no pending changes in libpq that
would mandate a major version bump (ie, nothing binary-incompatible,
AFAIK). We could ship it with the exact same version number, but then
how are people to tell whether they have a 7.0 or 7.1 libpq?

If there isn't any changes, why bump it?
--
Trond Eivind Glomsr�d
Red Hat, Inc.

Bruce Momjian <pgman@candle.pha.pa.us> writes:

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

Historically, all applications have been able to talk to newer servers,
so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients
can talk to 7.1 postmasters.

Great - that was what I wanted to know.

We usually do not go the other way, where 6.5 clients can not talk to
6.4 postmasters. I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

Thanks!

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Lamar Owen <lamar.owen@wgcr.org> writes:

Bruce Momjian wrote:

Trond Eivind Glomsr�d wrote:

How compatible with 7.0 and 7.1 be from an application standpoint?
Will applications linked with libraries from 7.0 be able to talk to
the 7.1 database? Any changes in library major versions? The other
way?

Historically, all applications have been able to talk to newer servers,
so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients
can talk to 7.1 postmasters.

We usually do not go the other way, where 6.5 clients can not talk to
6.4 postmasters. I believe 7.0->7.1 will be able to talk in any
7.0.X/7.1 client and server combination.

He's meaning the libpq version for dynamic link loading.

Not only - I'm interested in both issues.

Is the libpq.so lib changing versions (like the change from 6.5.x to
7.0.x changed from libpq.so.2.0 to libpq.so.2.1, which broke binary
RPM compatibility for other RPM's linked against libpq.so.2.0, which
failed when libpq.so.2.1 came on the scene

Huh? Shouldn't happen.

Not just libpq, though -- libpgtcl.so has also been problematic.

I don't think we ship that as a dynamic library.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Lamar Owen <lamar.owen@wgcr.org> writes:

Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

Now, that doesn't directly effect the PostgreSQL RPM's. What it does
effect is the guy who wants to install PHP from with PostgreSQL support
enabled and cannot because of a failed dependency. Who gets blamed?
PostgreSQL.

Trond may correct me on this, but I don't know of a workaround for
this.

There usually are no such problems, and I'm not aware of any specific
to postgresql either.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

[ Charset ISO-8859-1 unsupported, converting... ]

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Let them. It is their decision. Frankly, I have seen this attitude
before, and I don't like it. Just the mention that "Gee, if you don't
cooperate, we may yank you," is really a veiled threat. Now, I know you
aren't saying that, but the "if you don't play nice, we will drop you"
argument sounds a lot more like MS that a Linux vendor should be acting,
especially since they are not telling us what they want or assisting in
the work.

FWIW, I've never threatened to do so. If I wanted to, I would just do
it[1] - threats are bad and never cause anything but bad feelings.

Sounds good.

That being said, my favorite wishes (in addition to as much SQL
compliance and performance as possible, of course) are:

OK, here is a nice list I can address constructively:

* migration on upgrade

Yes, we have problems. 7.1 will have a more robust pg_dump, and I hope
that fixes most of those problems. As you see issues here, we need to
hear about it.

* old libraries being able to speak to newer databases, so old
binaries can continue working after database upgrades

We have always been able to do that. Old clients can talk to newer
databases, though new can't necessary talk to older. To the extent that
the client assumes a particular database structure, we have problems
there, especially psql. I most cases, those match the server, so I
think we are OK here, and most 3-rd party stuff doesn't touch the system
tables in areas that are changed frequently.

* good sonames on libraries - if a library hasn't changed, bumping the
number to show it's part of a new version isn't necesarry. If it is
backwards compatible, just bump the minor version, if it isn't, bump
the major version. Or even better, use versioned symbols (I don't
know how many other OSes than Linux and Solaris supports this,
though).

We only bump minor .so numbers, except for 6.5 I think where we had a
major overhaul of libpq and the major was bumped. I don't see another
major bump on the horizon. I don't think we have ever shipped a server
that could not talk to clients at least one major revison backwards.

The big question is how RPM's handle that. I have no idea.

As for assisting, at least Red Hat contributes to a lot of projects,
some of which are important to postgres on one or more platforms: gdb,
gcc, glibc and the linux kernel. There just isn't enough resources to
do everything, but I try to help out with the RPMs.

We only need help to the extent RPM people are asking for major feature
additions that affect only RPM/Linux, and frankly, the RPM/Linux users
should be supplying patches to us for that anyway. No need for the
company to get involved.

When we make patches for packages, we try to cooperate with the
author(s) to get them in - happily, we haven't had much of a need for
that with postgresql.

Yes, I have never seen one.

The "We are big. Just fix it and let us know when it is ready" attitude
does not work here, and that is what I am hearing mostly from the RPM
people.

I haven't heard anyone say that.

Some of the RPM users have made some demands that sound a little like
that. :-)

There must be a list of known problems. Let's hear them, so we can try
to solve them as a group. However, in general, we do not make dramatic
change to work around OS bugs, and do not plan to make major changes to
work around the limitations of RPM's.

I don't think there are any apart from the upgrade issues - if library
versioning follows the standard, that certainly won't be a problem.

I would love to get a detailed list of upgrade problems so we can be
sure 7.1 has them fixed. Certainly 7.1 is already a big improvement for
upgrades.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026