Re: queryId constant squashing does not support prepared statements

Поиск
Список
Период
Сортировка
От Álvaro Herrera
Тема Re: queryId constant squashing does not support prepared statements
Дата
Msg-id 202506261642.tlsahe6rp5gb@alvherre.pgsql
обсуждение исходный текст
Ответ на queryId constant squashing does not support prepared statements  (Sami Imseih <samimseih@gmail.com>)
Список 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)



В списке pgsql-hackers по дате отправления: