Re: statement logging / extended query protocol issues

Simon Riggs wrote:

> Looking more closely, I don't think either is correct. Both can be reset
> according to rewind operations - see DoPortalRewind().
>
> We'd need to add another bool onto the Portal status data structure.

AFAIK this is only an issue with SCROLLABLE cursors, which v3 portals
aren't.

> If queries are short and yet there is much fetching, we may see a
> program whose main delay is because of program-to-server delay because
> of fetching. So, I'd like to see that in the log, but I agree with your
> earlier comments that it should be a shorter log line.

I'm coming from the point of view of a user who wants to "just turn on
query logging". The mechanics of the portals aren't of interest to them.
Currently, "log_statement = all" produces markedly different output
depending on whether the extended query protocol is used or not, which
is very much an implementation detail..

How about "log_statement = verbose" or something similar to enable
logging of all the details, and have "all" just log Parse and the first
Execute?

Ideally, even Parse wouldn't be logged, but then we'd need a way to log
statements that error during Parse.

-O