Error if prepared statement name isn't unique

[Rich-Harris]

This is more an admission of incompetence on my part than anything, but on a number of occasions I've copy-pasted a query like this...

const { rows } = await pool.query({
  name: 'some-descriptive-name',
  text: `select thingamajig from flibbertigibbets where id = $1`,
  values: [id]
});

...and tweaked the query but forgotten to change the name:

const { rows } = await pool.query({
  name: 'some-descriptive-name',
  text: `select thingamajig from flibbertigibbets where id = $1 and active = true`,
  values: [id]
});

Typically, this results in subtle errors, by returning plausible but incorrect data.

I wonder if pg could help here by storing the text of a query that specifies a name, and erroring if it encounters another query with the same name but different text? Arguably not the library's job, but if my experience is anything to go by it could save a few developers from tearing their hair out, and deepen their gratitude towards this wonderful project.

Does that seem like a worthwhile addition? If so I'd be glad to try and rustle up a PR. Thank you!

[charmander]

Does that seem like a worthwhile addition?

I think it does!

[charmander]

(Note: null/undefined text should be allowed as well.)

[schrizsz]

Hi, we have a logging system in our microservices infrastructure that passes request unique id through services and also to postgresql queries. For that we add a /* cid: ${request_id} */ in the query. This "fix" breaks this possibility. Any advice?

[charmander]

@schrizsz That wouldn’t have worked before this fix either. This fix just makes it apparent. If you want to continue using named prepared statements but also delete them for new requests, you have to associate a client with a request, run DEALLOCATE <name>, and delete client.connection.parsedStatements[name].

Maybe setting the application name would work better if you were intending to go that far?