On Saturday, March 3, 2012 3:41:23 PM UTC-8, Chris Hanks wrote:
>
> I brought up the following in the comments of Jeremy's blog post on
> automatic statement caching, and he suggested that I bring it up here
> to get some input from other Sequel users.
>
> I'm thinking that when Sequel executes a prepared statement, it puts a
> line in the logs that looks something like "EXECUTE sequel_pgap_2 --
> args: [1]". The problem is that if specific portions of the logs
> require later review, it'll be difficult to determine what SQL queries
> were being performed at a given time ("sequel_pgap_2" won't
> necessarily map to the same SQL query between restarts of the app, and
> you won't be able to determine what it does map to without rewinding
> your logs to when the statement was prepared).
> Since it doesn't seem practical to use a more descriptive prepared
> statement name, the question is would it be useful to log the actual
> SQL query that was executed (such as "SELECT * FROM table WHERE (a =
> $1::int4)") alongside or in place of the current prepared statement
> execution line. Jeremy thinks that if a change is made here, it should
> probably also be made in the prepared statements plugin.
>
> Does anyone have any thoughts on this?
On Saturday, March 3, 2012 3:41:23 PM UTC-8, Chris Hanks wrote:
>
> I brought up the following in the comments of Jeremy's blog post on
> automatic statement caching, and he suggested that I bring it up here
> to get some input from other Sequel users.
>
> I'm thinking that when Sequel executes a prepared statement, it puts a
> line in the logs that looks something like "EXECUTE sequel_pgap_2 --
> args: [1]". The problem is that if specific portions of the logs
> require later review, it'll be difficult to determine what SQL queries
> were being performed at a given time ("sequel_pgap_2" won't
> necessarily map to the same SQL query between restarts of the app, and
> you won't be able to determine what it does map to without rewinding
> your logs to when the statement was prepared).
>
> Since it doesn't seem practical to use a more descriptive prepared
> statement name, the question is would it be useful to log the actual
> SQL query that was executed (such as "SELECT * FROM table WHERE (a =
> $1::int4)") alongside or in place of the current prepared statement
> execution line. Jeremy thinks that if a change is made here, it should
> probably also be made in the prepared statements plugin.
>
> Does anyone have any thoughts on this?
This makes sense for me for the pg_statement_cache extension, since the
prepared statements aren't controlled by the user.
For the prepared statements plugin, maybe we could try to use better names
by default. It's not possible to log the SQL there without modifying the
general prepared statement support.
Maybe it would be better to add a flag in the general prepared statement
support that could be set so that the SQL statement is logged? It could be
used by the prepared statement plugins and other code that automatically
creates prepared statements. I don't want to do it by default for manually
prepared statements, since the user should be giving them unique names.
What are other user's thoughts on this?
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/uvqfk5Lvf0YJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
