Re: Non-decimal integer literals - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Non-decimal integer literals
Date
Msg-id CAEZATCWE5udJVtQn6JJez8t+4ERgy1Fqj7x+T8qGMN6KfKUYow@mail.gmail.com
Whole thread Raw
In response to Re: Non-decimal integer literals  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Non-decimal integer literals  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
On Tue, 24 Jan 2023 at 00:47, Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
> Hi Dean, thanks for your work.
>
> But since PG_RETURN_NULL, is a simple return,
> now the "value" var is not leaked?
>

That originates from a prior commit:

ccff2d20ed Convert a few datatype input functions to use "soft" error reporting.

and see also a bunch of follow-on commits for other input functions.

It will only return NULL if the input is invalid and escontext is
non-NULL. You only identified a fraction of the cases where that would
happen. If we really cared about not leaking memory for invalid
inputs, we'd have to look at every code path using ereturn()
(including lower-level functions, and not just in numeric.c). I think
that would be a waste of time, and counterproductive -- trying to
immediately free memory for all possible invalid inputs would likely
complicate a lot of code, and slow down parsing of valid inputs.
Better to leave it until the owning memory context is freed.

Regards,
Dean



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Ranier Vilela
Date:
Subject: Re: Non-decimal integer literals