On 2016-10-03 14:49:20 -0400, Tom Lane wrote: > > On 2016-10-03 12:29:18 -0400, Tom Lane wrote: > >> The patch seems pretty successful in terms of being noninvasive to > >> the code. I think the major objection to it would be that we no > >> longer have any direct compiler-verified connection between the > >> signatures of the called functions in hstore/plpython and what > >> hstore_plpython thinks they are. > > > We could instead add a AssertVariableIsOfType(), besides the library > > lookup maybe? > > Hmm ... had not occurred to me that that might work on a function name. > I'll go try it.
I'm pretty sure it does, I've used it for that in the past. > Andres Freund <and...@anarazel.de> writes: > >> If we were to push forward with this idea, the remaining work > >> would be to fix the other two contrib transform modules similarly, > >> after which I would want to revert the changes in commit cac765820 > >> and later that suppressed linker errors for unresolved symbols in > >> contrib links. The possibility of getting back that error detection > >> is actually the main motivation for this IMO. > > > That'd be rather neat. > > I experimented with that aspect a bit today. For macOS it's sufficient > to remove the "-Wl,-undefined,dynamic_lookup" linker flag that cac765820 > added. However, ignoring unresolved symbols in shlibs is the default > on Linux, and while you can make it throw errors, that just leads to > errors for all the references into the core backend. Not very helpful. > AFAICS, GNU ld lacks any equivalent to macOS' -bundle_loader switch, > which is what we'd need to make this usable. Hm. I wonder if it's actually possible to link against the main backend, when compiling as a position-independent-executable... > A workable compromise for Linux might be to enable -Wl,-z,now which > changes unresolved symbol resolution from lazy to on-load. That would > at least guarantee that any testing whatsoever would detect incorrect > references, even if the bad call wasn't exercised. Hm, I think that's the default already no? At least linux has #define pg_dlopen(f) dlopen((f), RTLD_NOW | RTLD_GLOBAL) which should trigger that behaviour, and I do remember seing errors because of non-exercised function and variable references. Regards, Andres -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers