From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, 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-04-05 15:27:09 |
Message-ID: | CA+TgmoYOOCrfO26PGs8kWDCHhOkmvD--E5_8AR_Gwnx-hwhhtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 17, 2022 at 4:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Based on this review and the fact that there's been no new patch since
the original version, I've marked this Returned with Feedback in the
CommitFest.
If Amul decides to update the patch as Tom is describing, he can
reactivate the CommitFest entry at that time.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Yura Sokolov | 2022-04-05 15:40:52 | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Previous Message | Stephen Frost | 2022-04-05 15:25:36 | Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file |