Re: Improper use about DatumGetInt32
От | Peter Eisentraut |
---|---|
Тема | Re: Improper use about DatumGetInt32 |
Дата | |
Msg-id | c6eaa580-9f2e-f9d8-feb5-2b56db9d56f6@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Improper use about DatumGetInt32 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Improper use about DatumGetInt32
|
Список | 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 по дате отправления: