On Fri, Mar 18, 2022 at 1:17 AM Greg Stark <stark@mit.edu> wrote:
>
> On Fri, 11 Mar 2022 at 15:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Amul Sul <sulamul@gmail.com> writes:
>
> > > Yeah, that's true, I am too not sure if we really need to refactor
> > > all those; If we want, I can give it a try.
> >
> > The patch as-presented isn't very compelling for
> > lack of callers of the new function
>
> Tom, are you saying you think we're not interested in just adding this
> function unless it's part of this refactoring?
>
> Amul, do you think if we did numeric_to_int64/numeric_to_uint64 as a
> refactored API and a second patch that made numeric_pg_lsn and other
> consumers use it it would clean up the code significantly?
Sorry for the long absence.
Yes, I think we can do cleanup to some extent. Attaching the
following patches that first intend to remove DirectFunctionCall as
much as possible:
0001:
Refactors and moves numeric_pg_lsn to pg_lsn.c file. Function gut is
in numeric.c as numeric_to_uint64_type() generalised function that can
be used elsewhere too.
0002:
Does little more cleanup to pg_lsn.c file -- replace few
DirectFunctionCall1() by the numeric_to_uint64_type().
0003:
Refactors numeric_int8() function and replace few
DirectFunctionCall1() to numeric_int8 by the newly added
numeric_to_int64() and numeric_to_int64_type().
numeric_to_int64_type() version can be called only when you want to
refer to the specific type name in the error message like
numeric_to_uint64_type, e.g.MONEY type.
0004:
Adding float8_to_numeric and numeric_to_float8 by refactoring
float8_numeric and numeric_float8 respectively. I am a bit confused
about whether the type should be referred to as float8 or double.
Replaces a few DirectFunctionCall() calls by these c functions.
0005:
This one replaces all DirectFunctionCall needed for the numeric
arithmetic operations.
Regards,
Amul
