Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Zoltan Boszormenyi" <zb(at)cybertec(dot)at>
Cc: <pgsql-patches(at)postgresql(dot)org>, "Hans-Juergen Schoenig" <hs(at)cybertec(dot)at>
Subject: Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Date: 2008-03-25 00:23:50
Message-ID: 878x07odm1.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Zoltan Boszormenyi" <zb(at)cybertec(dot)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!

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2008-03-25 00:25:01 Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Previous Message Zoltan Boszormenyi 2008-03-25 00:11:07 Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1