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

From Zoltan Boszormenyi
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
Msg-id 47E84DC7.1010701@cybertec.at
Whole thread Raw
In response to Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
Gregory Stark írta:
> "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

OK, third version, the #define INT64PASSBYVAL is used now
for less #ifdef'd code, I used postgres.h for the defines for now.

As for the tsearch problem, it seems that bth tsearch and gist in general
uses the "internal" type for passing pointers to different datatypes around
for modifying them in-place, float4 among them. So, somewhere tsearch
or gist uses hardcoded passed-by-ref where it really a float4, not
"internal".
Someone with more knowledge about tsearch could look into this...

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/


Attachment

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Next
From: Bruce Momjian
Date:
Subject: Re: 2WRS [WIP]