From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Removing link-time cross-module refs in contrib |
Date: | 2016-10-03 18:36:39 |
Message-ID: | 20161003183639.fhlcz6zb5ylb3fil@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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. That is, if someone were to
> modify hstore and change the signature of say hstoreCheckKeyLen,
> this would not cause any compiler complaints in hstore_plpython,
> just runtime problems.
> A slightly ugly way of alleviating that risk would be to put the
> function typedefs right beside the externs in the originating
> modules, eg in hstore.h
>
> extern size_t hstoreCheckKeyLen(size_t len);
> +typedef size_t (*hstoreCheckKeyLen_t) (size_t len);
We could instead add a AssertVariableIsOfType(), besides the library
lookup maybe?
> 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.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-10-03 18:38:26 | Re: Macro customizable hashtable / bitmapscan & aggregation perf |
Previous Message | Stephen Frost | 2016-10-03 18:32:16 | Re: pgbench more operators & functions |