Last night, we packaged up v7.3.1 of PostgreSQL, our latest stable
release.
Purely meant to be a bug fix release, this one does have one major change,
in that the major number of the libpq library was increased, which means
that everyone is encouraged to recompile their clients along with this
up
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Good catch. Hmm this may be a serious problem because
> > there's no way to know the row count when we use EXECUTE
> > statements.
>
> I wonder if EXECUTE could/should be made to return the appropriate
> com
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > Good catch. Hmm this may be a serious problem because
> > > there's no way to know the row count when we use EXECUTE
> > > statements.
> >
> > I wonder if EXECUTE could/should be made to return the appropriate
> > command status
Hi all,
I'm planning an upgrade from 7.2.3 to 7.3.1 on some HP-UX systems.
With the major number bump in 7.3.1 I was expecting to be able to do
this upgrade without a flag day to re-compile clients, however due to
misnaming of the PostgreSQL shared libraries on HP-UX I can't.
A summary of the pr
Giles Lean <[EMAIL PROTECTED]> writes:
> 1. the libraries are installed with their base names such as
>'libpq.sl' being regular files, with versioned names being
>symbolic links to the base names:
>This should be the other way around:
Probably so. I had not realized that HP's linker i
Tom Lane wrote:
> Probably so. I had not realized that HP's linker is affected by which
> way the symlinks run, but it appears that it is.
I've just spoken to someone who knows more about the HP-UX toolchain
than I do.
The situation is that the library can have an internal name if the +h
optio
I wrote:
> My recommendation (with a pinch of salt, since I'm still not a HP-UX
> toolchain guru) is to add
>
> +h lib$(NAME)$(DLSUFFIX).$SO_MAJOR_VERSION)
>
> to the HP-UX LINK.shared line in src/Makefile.shlib, and to change the
> way the symlinks run as well, so that libpq.sl is a link to
