On Wed, Mar 8, 2023 at 2:19 PM Michael Paquier <mich...@paquier.xyz> wrote:
>
> On Fri, Mar 03, 2023 at 09:37:27AM +0900, Michael Paquier wrote:
> > Thanks for double-checking, applied 0001 to finish this part of the
> > work. I am attaching the remaining bits as of the attached, combined
> > into a single patch.
>
> Doing so as a single patch was not feeling right as this actually
> fixes issues with the location calculations for the Const node, so I
> have split that into three commits and finally applied the whole.
>
> As a bonus, please see attached a patch to apply the normalization to
> CALL statements using the new automated infrastructure. OUT
> parameters can be passed to a procedure, hence I guess that these had
> better be silenced as well. This is not aimed at being integrated,
> just for reference.
> --
> Michael
I tested it. all normally works fine. only 1 corner case:
set pg_stat_statements.track = 'all';
drop table if Exists cp_test;
CREATE TABLE cp_test (a int, b text);
CREATE or REPLACE PROCEDURE ptest1(x text) LANGUAGE SQL AS $$ INSERT
INTO cp_test VALUES (1, x); $$;
CREATE or REPLACE PROCEDURE ptest3(y text)
LANGUAGE SQL
AS $$
CALL ptest1(y);
CALL ptest1($1);
$$;
SELECT pg_stat_statements_reset();
CALL ptest3('b');
SELECT calls, toplevel, rows, query FROM pg_stat_statements ORDER BY
query COLLATE "C";
returns:
calls | toplevel | rows | query
-------+----------+------+------------------------------------
1 | t | 0 | CALL ptest3($1)
2 | f | 2 | INSERT INTO cp_test VALUES ($2, x)
1 | t | 1 | SELECT pg_stat_statements_reset()
here, the intermediate CALL part is optimized away. or should I expect
CALL ptest1($1) also in pg_stat_statements?
