Itagaki Takahiro escreveu:
> Here is a patch to add ProcessUtility_hook to handle all DDL
> commands in user modules. (ProcessUtility_hook_20091021.patch)
> It adds a global variable 'ProcessUtility_hook' and
> export the original function as 'standard_ProcessUtility'.
> 
I've reviewed your patch. It applies cleanly and compiles without warnings. It
lacks documentation. Could you update it?

The functionality is divided in two parts. The first part is a hook in the
utility module. The idea is capture the commands that doesn't pass through
executor. I'm afraid that that hook will be used only for capturing non-DML
queries. If so, why don't we hack the tcop/postgres.c and grab those queries
from the same point we log statements? This feature is similar to the executor
one. But in the executor case, we use the plan for other things. Other
utilities are (i) using that hook to filter out some non-DML commands and (ii)
developing some non-DML replication mechanism for trigger-based replication
solutions.

The second part is to use that hook to capture non-DML commands for
pg_stat_statements module. Do we need to have rows = 0 for non-DML commands?
Maybe NULL could be an appropriate value. The PREPARE command stopped to count
 the number of rows. Should we count the rows in EXECUTE command or in the
PREPARE command? The other command that doesn't count properly is COPY. Could
you fix that? I'm concerned about storing some commands that expose passwords
like CREATE ROLE foo PASSWORD 'secret'; I know that the queries are only
showed to superusers but maybe we should add this information to documentation
or provide a mechanism to exclude those commands.

I don't know if it is worth the trouble adding some code to capture VACUUM and
ANALYZE commands called inside autovacuum.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to