plpgsql is not ready for prime time

We have enough different shared libraries now that it'd be a good idea
to try to eliminate most of that cruft from the individual module
makefiles, replacing it with definitions made in the port makefiles.
But it's a bit too late in the 6.4 beta cycle to try to do that for 6.4,
I think --- the testing problem looms too large. Something for next time.

I had a patch to do just this earlier this year for 6.4, but I changed
jobs before I could submit it, then other patches were applied that made
my patch fail. I just finally got access to a machine to redo my patch,
but it wasn't in time for 6.4 beta. I will have it in the first month or
so after 6.4 is released...

darrenk

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

... it does not build on HPUX, nor on any other platform that requires
specialized switches to build shared libraries. I recommend the author
consult the makefile for libpq, and transpose the necessary fooling
around into plpgsql. (On HPUX it fails for lack of -fPIC in the compile
commands for the pl/plpgsql/src subdirectory; there might also be
problems in the link command, but the compile commands are certainly
wrong.)

I have made change to configure/configure.in and added a Makefile.in to help
with the problem (I had problems compiling for UnixWare). I will be testing
[the UnixWare part of] the patches over the new few days. I will submit the
after I complete prlimiary testing. I will also mail the patch to anyone else
who would like to test for a specific port.

We have enough different shared libraries now that it'd be a good idea
to try to eliminate most of that cruft from the individual module
makefiles, replacing it with definitions made in the port makefiles.
But it's a bit too late in the 6.4 beta cycle to try to do that for 6.4,
I think --- the testing problem looms too large. Something for next time.

I aggree that the shared library handling needs to be standardized and the
port specific information moved to the port specific Makefile.

BTW there is also a configuration check that needs to be applied: the
pl/tcl subdirectory should be built only if a *shared library* version
of Tcl is available. I happen to have only a static version of libtcl.a
installed, which is fine for pgtclsh, but pl/tcl tries to link with it
and falls over...

Hmmmm.... I don't now autoconf well enough (yet) to handle this change.

[...]
regards, tom lane

--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |

Billy G. Allie wrote:

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

... it does not build on HPUX, nor on any other platform that requires
specialized switches to build shared libraries. I recommend the author
consult the makefile for libpq, and transpose the necessary fooling
around into plpgsql. (On HPUX it fails for lack of -fPIC in the compile
commands for the pl/plpgsql/src subdirectory; there might also be
problems in the link command, but the compile commands are certainly
wrong.)

I have made change to configure/configure.in and added a Makefile.in to help
with the problem (I had problems compiling for UnixWare). I will be testing
[the UnixWare part of] the patches over the new few days. I will submit the
after I complete prlimiary testing. I will also mail the patch to anyone else
who would like to test for a specific port.

We have enough different shared libraries now that it'd be a good idea
to try to eliminate most of that cruft from the individual module
makefiles, replacing it with definitions made in the port makefiles.
But it's a bit too late in the 6.4 beta cycle to try to do that for 6.4,
I think --- the testing problem looms too large. Something for next time.

I aggree that the shared library handling needs to be standardized and the
port specific information moved to the port specific Makefile.

BTW there is also a configuration check that needs to be applied: the
pl/tcl subdirectory should be built only if a *shared library* version
of Tcl is available. I happen to have only a static version of libtcl.a
installed, which is fine for pgtclsh, but pl/tcl tries to link with it
and falls over...

Hmmmm.... I don't now autoconf well enough (yet) to handle this change.

I'd really appreciated to have PL/pgSQL installed in
template1 with the 6.4 release. But I see that the problems
we have with the make process of shared libraries is too much
trouble that close to release.

Since PL/Tcl also causes trouble let's put both into 6.5 and
don't delay 6.4 longer than required for the other fixes.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #