Some questions about context handling

[stephan0h]

Hello,
I recently enabled pghistory.middleware.HistoryMiddleware to track who is changing what. Now my colleague was alarmed because there are so many more queries. He stumbled across the calls to set_config(). So I did some research.
Why is it necessary to call set_config() for each and every SQL-statement - even selects? Because I would assume that context info is only necessary for inserts/updates/deletes when the triggers are actually writing to the event tables.
The next question is (I have not tested yet): does this have any performance implications? I suppose a call to set_config() is cheap - but is it causing extra round trips to the database?
Thanks for enlightening me :-)
Kind regards,
Stephan

[wesleykendall]

1. No extra trips to the DB. This gets injected in the SQL itself in django DB connection hooks
2. They are extremely fast queries to set variables (0.04MS for me locally). I'd recommend profiling the cost of set_config yourself if curious, i.e. explain analyze select set_config('variable.name', 'value', true);
3. You're right that doing this on SELECTs is likely unnecessary. Wanna open a pull request? Any SQL that starts with SELECT should be able to be safely ignored, although there may be edge cases I'm not thinking about (multi-statement queries that get executed).

For 3, I can open a PR too, but it may be a week or more. It's this function where you can check the SQL statement and avoid injecting those variable declarations.

I assume you understand, but those variables are for the triggers that track history. Although one could also do a round-trip SQL once the moment the context manager is entered, I was hesitant to introduce more round-trip queries in the mix, especially if you didn't do any DB operations. Setting the variables directly ahead of the SQL also helps more with connection poolers. I'm also open to contributors setting the variables once in the context manager just as long as there's a setting to provide both modes