Re: Bug in pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Bug in pg_stat_statements
Date
Msg-id CAA5RZ0sNkuaNngrXPBsDTpdyHmFJxFPDa=ehgeGk6m1+UVTp9g@mail.gmail.com
Whole thread Raw
In response to Re: Bug in pg_stat_statements  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
>
> > > On Fri, Oct 24, 2025 at 07:04:59PM -0500, Sami Imseih wrote:
> > > v4 corrects some code comments.
> >
> > The fix in the first patch looks good, thanks.
>
> Yeah, I think this general idea is sensible.  However, I think we should
> take it one step further and just remove last_loc entirely.  I think
> this makes the code a bit clearer.  How about the attached?

getting rid of last_loc makes sense because the list is sorted makes
sense. I like this, definitely cleaner.

One minor comment is to change is to remove the "let's save it" but
in the comments, as we are no longer saving a last_loc.

                /*
-                * We have a valid location for a constant that's not
a dupe, let's
-                * save it.  Lex tokens until we find the desired constant.
+                * We have a valid location for a constant that's not
a dupe. We Lex
+                * tokens until we find the desired constant.
                 */


--
Sami



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Next
From: Bertrand Drouvot
Date:
Subject: Re: Consistently use the XLogRecPtrIsInvalid() macro