Re: Improper use about DatumGetInt32 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Improper use about DatumGetInt32
Date
Msg-id c6eaa580-9f2e-f9d8-feb5-2b56db9d56f6@enterprisedb.com
Whole thread Raw
In response to Re: Improper use about DatumGetInt32  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improper use about DatumGetInt32  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 2020-12-25 08:45, Michael Paquier wrote:
>> If we really think that we ought to differentiate, then we could do what
>> pg_stat_statement does, and have a separate C function that's called
>> with the obsolete signature (pg_stat_statements_1_8 et al).
> With the 1.8 flavor, it is possible to pass down a negative number
> and it may not fail depending on the number of blocks of the relation,
> so I think that you had better have a compatibility layer if a user
> has the new binaries but is still on 1.8.  And that's surely a safe
> move.

I think on 64-bit systems it's actually safe, but on 32-bit systems 
(with USE_FLOAT8_BYVAL), if you use the new binaries with the old 
SQL-level definitions, you'd get the int4 that is passed in interpreted 
as a pointer, which would lead to very bad things.  So I think we need 
to create new functions with a different C symbol.  I'll work on that.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Bharath Rupireddy
Date:
Subject: Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW