Re: Proposal for internal Numeric to Uint64 conversion function.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Amul Sul <sulamul(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal for internal Numeric to Uint64 conversion function.
Date: 2022-03-17 20:02:27
Message-ID: 799416.1647547347@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> On Fri, 11 Mar 2022 at 15:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

Pretty much, yeah. I'm way more interested in cleaning up the code
we have than in making things prettier for hypothetical future
call sites. In particular, the problem with writing an API in a
vacuum is that you have little evidence that it's actually useful
as given (e.g., did you handle error cases in a useful way). If we
create a numeric_to_int64 that is actually used right away by some
existing callers, then we've got some evidence that we did it right;
and then introducing a parallel numeric_to_uint64 is less of a leap
of faith.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-03-17 20:05:23 Re: Optimize external TOAST storage
Previous Message Greg Stark 2022-03-17 19:58:10 Re: proposal: enhancing plpgsql debug API - returns text value of variable content