fix(pg): Do not add SQLCommenter comments to prepared statements

[raphael-theriault-swi]

Which problem is this PR solving?

Currently the pg instrumentation will add SQLCommenter comments to any query it can, even prepared ones. In the case of prepared statements this usually results in the trace context within the comment being incorrect for all but the first instance of the query being run.

Short description of the changes

This adds a simple check to skip adding the comment for prepared statements. See https://node-postgres.com/features/queries#prepared-statements.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.86%. Comparing base (a5b5614) to head (1cb3ed7).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2456      +/-   ##
==========================================
+ Coverage   90.85%   90.86%   +0.01%     
==========================================
  Files         161      161              
  Lines        7859     7858       -1     
  Branches     1614     1612       -2     
==========================================
  Hits         7140     7140              
+ Misses        719      718       -1     

Files with missing lines	Coverage Δ
...elemetry-instrumentation-pg/src/instrumentation.ts	90.21% <100.00%> (+0.48%)	⬆️

[maryliag]

results in the trace context within the comment being incorrect for all but the first instance of the query being run

can you explain a little more on this? why the comment would be only valid for the first execution of the query? what makes the following executions different?
I imagine the difference in executions mean different values on the prepared statement, but I don't think the comments itself are about the values, so I'm not following why it would no longer be valid for future executions.

[raphael-theriault-swi]

The comments contain the trace context at the time the query is created. So with prepared statements, when executing the query for the first time the comment will be created with the current trace context, but every subsequent execution will use that same trace context since the query is cached on the database side. So the comment now forever references a trace and span that have long stopped existing.

It makes a lot more sense when you look at how prepared statements actually work at the database level. It's actually a two step process, one PREPARE list (int, int) AS SELECT * FROM todos LIMIT $1 OFFSET $2 /* trace context */; step which caches the raw query without any parameter values, followed by any number of EXECUTE list(100, 0); which only include the cached name and argument values.

[maryliag]

@pichlermarc is this consider a breaking change? Just want to make sure everything is properly flagged before giving any approvals

[raphael-theriault-swi]

Wouldn't this be a bugfix rather than a breaking change given this behaviour is always incorrect ? I doubt anyone is depending on the instrumentation producing spans that are just totally invalid.

[blumamir]

Thanks for contributing this fix @raphael-theriault-swi

This LGTM, added 2 nits. I don't think this is a breaking change, as current behavior is a bug.

[maryliag]

Thank you for working on these changes and the feedback!

[blumamir]

Thank you for the contribution.