Re: ProcessUtility_hook - Mailing list pgsql-hackers

From Takahiro Itagaki
Subject Re: ProcessUtility_hook
Date
Msg-id 20091210113301.54B9.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: ProcessUtility_hook  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ProcessUtility_hook  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: ProcessUtility_hook
Next
From: Robert Haas
Date:
Subject: Re: ProcessUtility_hook