From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: queryId constant squashing does not support prepared statements |
Date: | 2025-06-26 16:42:46 |
Message-ID: | 202506261642.tlsahe6rp5gb@alvherre.pgsql |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-Jun-25, Michael Paquier wrote:
> On Tue, Jun 24, 2025 at 07:45:15PM +0200, Alvaro Herrera wrote:
> > + /*
> > + * If we have an external param at this location, but no lists are
> > + * being squashed across the query, then we skip here; this will make
> > + * us print print the characters found in the original query that
> > + * represent the parameter in the next iteration (or after the loop is
> > + * done), which is a bit odd but seems to work okay in most cases.
> > + */
> > + if (jstate->clocations[i].extern_param && !jstate->has_squashed_lists)
> > + continue;
>
> + * us print print the characters found in the original query that
>
> The final commit includes this comment, with a s/print print/print/
> required.
Ugh. Fixed, thanks for noticing that.
> > Lastly, I decided not to do a catversion bump. As far as I can tell,
> > changes in the jumbling functions do not need them. I tried an
> > 'installcheck' run with a datadir initdb'd with the original code, and
> > it works fine.
>
> This reminds me of 4c7cd07aa62a and this thread:
> https://www.postgresql.org/message-id/1364409.1727673407@sss.pgh.pa.us
>
> Doesn't the change in the Param structure actually require one because
> it can change the representation of some SQL functions? I am not
> completely sure.
Hmm, but the Param structure didn't actually change; only its jumbling
function did (and others that rely on LocationLen). So I think what
could happen here if there's no catversion is that somebody has a
pg_stat_statements populated with query Ids for some queries that have a
different queryIds when computed with the new code. So they're going to
have duplicates in pg_stat_statements. I think this is a pretty minor
problem, so I'm not inclined to do a catversion bump for it.
Anyway we have one due to 0cd69b3d7ef3, so it's moot now. (But it's a
good discussion to have, for the future.)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Niemand ist mehr Sklave, als der sich für frei hält, ohne es zu sein."
Nadie está tan esclavizado como el que se cree libre no siéndolo
(Johann Wolfgang von Goethe)
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2025-06-26 16:45:16 | Re: Documentation fix on pgbench \aset command |
Previous Message | Yugo Nagata | 2025-06-26 16:31:48 | Re: Documentation fix on pgbench \aset command |