On Mon, Dec 01, 2025 at 05:31:43PM +0530, Amul Sul wrote:
> On Mon, Dec 1, 2025 at 12:32 PM Michael Paquier wrote:
>> There were two more functions that btree_gin.c is pointing at that
>> could to the switch: timestamp->timestamptz and its opposite. This
>> also shaves some code, which is nice.
On Mon, Dec 1, 2025 at 12:32 PM Michael Paquier wrote:
>
> On Fri, Nov 28, 2025 at 09:46:43AM +0530, Amul Sul wrote:
> > I have attached patch 0002 that renames it. I also updated patch 0001
> > to accommodate Amit's comment suggestions.
>
> Thanks, applied this one after more tweaks. Regarding 0
On Fri, Nov 28, 2025 at 09:46:43AM +0530, Amul Sul wrote:
> I have attached patch 0002 that renames it. I also updated patch 0001
> to accommodate Amit's comment suggestions.
Thanks, applied this one after more tweaks. Regarding 0002, just
doing a renaming makes me a bit uncomfortable after a sec
On Fri, Nov 28, 2025 at 6:16 AM Michael Paquier wrote:
>
> On Thu, Nov 27, 2025 at 06:18:32PM +0900, Amit Langote wrote:
> > On Thu, Nov 27, 2025 at 4:58 PM Amul Sul wrote:
> >> One question: Regarding date2timestamp_no_overflow(), should we rename
> >> it to date2double? We can't use date2timest
On Thu, Nov 27, 2025 at 06:18:32PM +0900, Amit Langote wrote:
> On Thu, Nov 27, 2025 at 4:58 PM Amul Sul wrote:
>> One question: Regarding date2timestamp_no_overflow(), should we rename
>> it to date2double? We can't use date2timestamp_safe because we already
>> have that function. The renaming is
On Thu, Nov 27, 2025 at 4:58 PM Amul Sul wrote:
> On Thu, Nov 27, 2025 at 6:48 AM Amit Langote wrote:
> > On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> > > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > > It seems to me that it is important to keep documented the overfl
On Thu, Nov 27, 2025 at 6:48 AM Amit Langote wrote:
>
> On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote
> > > wrote:
> > >> []
> >
> > It seems to me that it is important
On Thu, Nov 27, 2025 at 10:28 AM Michael Paquier wrote:
> On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote:
> > I’m fine with updating all core callers to use the new *_safe(... Node
> > *escontext) APIs all in one patch. However, we could consider keeping
> > the existing *_opt_overfl
On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote:
> I’m fine with updating all core callers to use the new *_safe(... Node
> *escontext) APIs all in one patch. However, we could consider keeping
> the existing *_opt_overflow() functions as thin wrappers over the new
> ones, to avoid bre
On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote
> > wrote:
> >> * The rename from *_opt_overflow to *_overflow_safe could be made a
> >> separate patch (say 0002), so it can be dis
On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> On Wed, Nov 26, 2025 at 5:41 PM Amit Langote wrote:
>> * The rename from *_opt_overflow to *_overflow_safe could be made a
>> separate patch (say 0002), so it can be discussed separately. For
>> example, whether to keep the old *_opt_ove
On Wed, Nov 26, 2025 at 5:41 PM Amit Langote wrote:
>
> Hi,
>
> On Wed, Nov 26, 2025 at 8:43 PM Michael Paquier wrote:
> > On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> > > This continues the previous refactoring commit [1] where we adopted
> > > soft error reporting for some numeri
On Wed, Nov 26, 2025 at 5:13 PM Michael Paquier wrote:
>
>
> Hmm. Following the previous example you have quoted, I am wondering
> if we'd tweak the names a bit differently. Rather than the
> popo_overflow_safe() pattern from your patch, I would choose a simpler
> popo_safe() as naming conventio
Hi,
On Wed, Nov 26, 2025 at 8:43 PM Michael Paquier wrote:
> On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> > This continues the previous refactoring commit [1] where we adopted
> > soft error reporting for some numeric functions. This patch applies
> > the same pattern to the date/t
On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> This continues the previous refactoring commit [1] where we adopted
> soft error reporting for some numeric functions. This patch applies
> the same pattern to the date/timestamp function. The change ensures
> consistency by utilizing the
Hi,
The attached patch proposes to use soft error reporting infrastructure
for the date/timestamp conversion function, which currently depends on
integer variables to control error throwing.
This continues the previous refactoring commit [1] where we adopted
soft error reporting for some numeric
16 matches
Mail list logo
