pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...

Peter Eisentraut - PostgreSQL <petere@hub.org> writes:

Add dynamic_library_path parameter and automatic appending of shared
library extension.

Looks good. One tiny nit: I think that DLSUFFIX should be appended if
the given basename doesn't contain any '.', rather than first trying
the name as-is. The problem with doing the latter is that the presence
of a file or subdirectory named "foo" would prevent us from loading
"foo.so" correctly.

Looking ahead, there's a lot of subsidiary work that should now happen:

1. createlang should no longer insert libdir or dlsuffix into the
function declarations it makes (so building createlang from
createlang.sh won't be necessary anymore).

2. Likewise for CREATE FUNCTION commands in regress tests.

3. CREATE FUNCTION documentation should now recommend using relative
path and omitting suffix, rather than using full absolute pathname.
Update examples in SGML docs, src/tutorial/.

Maybe some other places too. Are you planning to do all that, or should
we put it on the to-do list for someone else?

regards, tom lane

Tom Lane writes:

Looks good. One tiny nit: I think that DLSUFFIX should be appended if
the given basename doesn't contain any '.', rather than first trying
the name as-is.

That won't work if the basename already contains a '.', as is possible if
some version is embedded in the library name. Libtool sometimes creates
such libraries.

The problem with doing the latter is that the presence of a file or
subdirectory named "foo" would prevent us from loading "foo.so"
correctly.

Perhaps we should try appending the extension first? This would model
libtool's libltdl more closely. If we encourage leaving off the extension
in load commands then this could be the better way. Of course we could
also check if the candidate file is a real file first.

1. createlang should no longer insert libdir or dlsuffix into the
function declarations it makes

How do we handle the case where the user changed the path? Do we say,
"$libdir needs to be in the path or you're on your own"?

I like this better: Let createlang set the path to '$libdir/plpgsql.so'
(literally) and substitute $libdir independend of the current mechanism.
That would survive an update.

2. Likewise for CREATE FUNCTION commands in regress tests.

I'd prefer to keep a few variations of each.

3. CREATE FUNCTION documentation should now recommend using relative
path and omitting suffix, rather than using full absolute pathname.
Update examples in SGML docs, src/tutorial/.

The create function ref page needs some editorial changes which I will get
to in the next few days.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

1. createlang should no longer insert libdir or dlsuffix into the
function declarations it makes

How do we handle the case where the user changed the path? Do we say,
"$libdir needs to be in the path or you're on your own"?

Seems OK to me, but ...

I like this better: Let createlang set the path to '$libdir/plpgsql.so'
(literally) and substitute $libdir independend of the current mechanism.

'$libdir/plpgsql', please, no platform dependencies. But OK otherwise.

regards, tom lane

Tom Lane writes:

1. createlang should no longer insert libdir or dlsuffix into the
function declarations it makes (so building createlang from
createlang.sh won't be necessary anymore).

createlang tries to be helpful by trying test -f $the_file first, to guard
against attempts to load PL/Tcl when no Tcl support was configured. This
approach has a few other subtle flaws: it requires createlang to be run
on the server machine and under the same user account as the server.
Maybe we could devise another way to determine gracefully whether a given
PL is installed.

2. Likewise for CREATE FUNCTION commands in regress tests.

The shared objects used in the regression test are not located relative to
the $libdir. Some for the various tutorials, examples.

3. CREATE FUNCTION documentation should now recommend using relative
path and omitting suffix, rather than using full absolute pathname.

Details in the Programmer's Guide now.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

createlang tries to be helpful by trying test -f $the_file first, to guard
against attempts to load PL/Tcl when no Tcl support was configured. This
approach has a few other subtle flaws: it requires createlang to be run
on the server machine and under the same user account as the server.
Maybe we could devise another way to determine gracefully whether a given
PL is installed.

Try eliminating the test entirely. CREATE FUNCTION now checks to make
sure that it can find the specified library (and that the named function
exists therein), so as long as createlang aborts on CREATE FUNCTION
failure, I see no need for a separate test.

2. Likewise for CREATE FUNCTION commands in regress tests.

The shared objects used in the regression test are not located relative to
the $libdir. Some for the various tutorials, examples.

Duh. Never mind that then ...

regards, tom lane