Open olirice opened 1 year ago
cc @kav
current hold up on this is that we want to log the graphql queries at LOG
level (which is just log!("graphql {statement}");
from pgrx prelude), but only if the log_statement
in postgresql.conf
is set to mod
or all
@imor any ideas of how to check that setting efficiently?
Executing the following SQL once for each GraphQL query shouldn't add too much overhead:
select setting from pg_settings
where name = 'log_statement';
I'd rather not do that if we can avoid it. for now I'll add debug level logging since that isn't impacted
I'd rather not do that if we can avoid it. for now I'll add debug level logging since that isn't impacted
Is that because reading from pg_settings
can be expensive, or there's some other reason? If the concern is inefficiency, we can also move this to when we read the context. That should be infrequent enough.
yeah the concern was efficiency. adding to the context is a good idea, I'll check that out
GraphQL queries are typically passed as arguments to a prepared statement and are not logged. Transpired SQL queries executed via SPI are similarly unlogged. That makes it difficult for users to debug their own queries
This issue is to add debug level logging for:
with a trace_id
We should also add logging at the warning or error level for things like like naming collisions