Re: queryId constant squashing does not support prepared statements

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-05-22 11:43:36
Message-ID: 202505221143.btgupjfus2mm@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-May-22, Dmitry Dolgov wrote:

> Just to call this out, I don't think there is an agreement on squashing
> Params, which you have added into 0002.

Actually I think we do have agreement on squashing PARAM_EXTERN Params.
https://postgr.es/m/3086744.1746500983@sss.pgh.pa.us

> Now, both flavour of the proposed solution could be still concidered too
> invasive to be applied as a bug fix. I personally don't see it like
> this, but I'm obviously biased. This leads us to following decisions to
> be made:
>
> * Is modifying parser (either adding a new node or modifying an existing
> one) acceptable at this stage? I guess it would be enough to collect
> couple of votes yes/no in this thread.

IMO adding a struct as suggested is okay, especially if it reduces the
overall code complexity. But we don't want a node, just a bare struct.
Adding a node would be more troublesome.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-05-22 11:44:39 Re: Retiring some encodings?
Previous Message Christoph Moench-Tegeder 2025-05-22 10:47:09 Re: Feature Suggestion: Make synchronous_commit a table level property