Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ... - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...
Date
Msg-id Pine.LNX.4.30.0105172111490.757-100000@peter.localdomain
Whole thread Raw
In response to Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...
Next
From: Peter Eisentraut
Date:
Subject: Maintaining HISTORY