Re: Improper use about DatumGetInt32

On 2020-Dec-03, Peter Eisentraut wrote:

> On 2020-11-30 16:32, Alvaro Herrera wrote:
> > On 2020-Nov-30, Peter Eisentraut wrote:
> >
> > > Patch updated this way. I agree it's better that way.
> >
> > Thanks, LGTM.
>
> For a change like this, do we need to change the C symbol names, so that
> there is no misbehavior if the shared library is not updated at the same
> time as the extension is upgraded in SQL?

Good question. One point is that since the changes to the arguments are
just in the way we read the values from the Datum C-values, there's no
actual ABI change. So if I understand correctly, there's no danger of a
crash; there's just a danger of misinterpreting a value.

I don't know if it's possible to determine (at function execution time)
that we're running with the old extension version; if so it might
suffice to throw a warning but still have the SQL function run the same
C function.

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).