"Zoltan Boszormenyi" <zb@cybertec.at> writes:
> Zoltan Boszormenyi írta:
>> Gregory Stark írta:
>>> 4) Your problems with tsearch and timestamp etc raise an interesting
>>> problem.
>>> We don't need to mark this in pg_control because it's a purely a run-time
>>> issue and doesn't affect on-disk storage. However it does affect ABI
>>> compatibility with modules. Perhaps it should be added to
>>> PG_MODULE_MAGIC_DATA.
>>
>> I am looking into it.
>
> Do you think it's actually needed?
> PG_MODULE_MAGIC_DATA contains the server version
> the external module was compiled for. This patch won't go to
> older versions, so it's already protected from the unconditional
> float4 change. And because you can't mix server and libraries
> with different bitsize, it's protected from the conditional int64,
> float8, etc. changes.
Right, it does seem like we're conservative about adding things to
PG_MODULE_MAGIC. As long as this is hard coded based on HAVE_LONG_INT_64 then
we don't strictly need it. And I don't see much reason to make this something
the user can override.
If there are modules which use the wrong macros and assume certain other data
types are pass-by-reference when they're not then they're going to fail
regardless of what version of postgres they're compiled against anyways.
So I would say in response to your other query to _not_ use pg_config_manual.h
which is intended for variables which the user can override. If you put
anything there then we would have to worry about incompatibilities.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
