| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Refactor query normalization into core query jumbling |
| Date: | 2025-12-19 06:49:29 |
| Message-ID: | aUT1eblRYpwB1nC7@ip-10-97-1-34.eu-west-3.compute.internal |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Dec 18, 2025 at 06:44:17PM -0600, Sami Imseih wrote:
> For the second point, since JumbleState can be shared by multiple
> extensions, hooks should receive it as a const pointer. This
> signals read-only intent and prevents extensions from
> accidentally modifying it through the hook. This change is in
> 0002. This does mean that extensions will need to update their
> hooks, but I do not see that as an issue for a major version.
I can see that 0001 is doing:
-static void fill_in_constant_lengths(JumbleState *jstate, const char *query,
and then:
+static void
+fill_in_constant_lengths(const JumbleState *jstate, const char *query,
Should the const addition be in 0002? But...
While looking at fill_in_constant_lengths(), I can see that it is doing:
locs = jstate->clocations;
and then things like:
locs[i].length = -1
or
locs[i].length = strlen(yyextra.scanbuf + loc)
While this is technically correct so the compiler does not complain (because
clocations is a non const pointer in JumbleState and the added const does not
apply to what clocations points to), I think that adding const here is misleading.
Indeed, the function clearly modifies data accessible through the parameter.
Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2025-12-19 07:02:49 | Re: Report bytes and transactions actually sent downtream |
| Previous Message | Xuneng Zhou | 2025-12-19 06:45:47 | Re: Sequence Access Methods, round two |