Re: ProcessUtility_hook
| От | Takahiro Itagaki |
|---|---|
| Тема | Re: ProcessUtility_hook |
| Дата | |
| Msg-id | 20091210113301.54B9.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
| Ответ на | Re: ProcessUtility_hook (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: ProcessUtility_hook
|
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > Why does this patch #ifdef out the _PG_fini code in pg_stat_statements? That's because _PG_fini is never called in current releases. We could remove it completely, but I'd like to leave it for future releases where _PG_fini callback is re-enabled. Or, removing #ifdef (enabling _PG_fini function) is also harmless. > Where you check for INSERT, UPDATE, and DELETE return codes in > pgss_ProcessUtility, I think this deserves a comment explaining that > these could occur as a result of EXECUTE. It wasn't obvious to me, > anyway. Like this? /** Parse command tag to retrieve the number of affected rows.* COPY command returns COPY tag. EXECUTE command might returnINSERT,* UPDATE, or DELETE tags, but we cannot retrieve the number of rows* for SELECT. We assume other commands alwaysreturn 0 row.*/ > It seems to me that the current hook placement does not address this complaint > >> I don't see why the hook function should have the ability to > >> editorialize on the behavior of everything about ProcessUtility > >> *except* the read-only-xact check. I moved the initialization code of completionTag as the comment, but check_xact_readonly() should be called before the hook. Am I missing something? Regards, --- Takahiro Itagaki NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: