Re: libpq API incompatibility between 7.4 and 8.0

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