Re: statement logging / extended query protocol issues

On Thu, 2005-09-08 at 13:14 +1200, Oliver Jowett wrote:
> Simon Riggs wrote:
> > On Tue, 2005-09-06 at 07:47 +0000, Oliver Jowett wrote:
> >>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.
> >
> > OK, that may be so, but the internals don't know that. If I use atEnd or
> > atStart then messages would differ from v3 to v2. It would then be easy
> > to confuse v2 cursor actions with multiple re-executions in v3. I want
> > to be able to look at the log and work out what happened, not to start
> > asking questions like "do you use v2, v3 or a mix of both?".
>
> Uh, but the logging in question only runs from exec_execute_message,
> which is explicitly handling a v3 Execute message, not an EXECUTE or
> FETCH from somewhere else? If that can be confused with a v2 query, then
> we should be logging it in such a way that it doesn't get confused (this
> is one reason why I don't like your approach of synthesizing
> FETCH/EXECUTE statements that were never actually submitted by the client).
>
> I don't think we should worry about trying to support v3 Execute against
> a SCROLLABLE cursor created via DECLARE that has been rewound -- that's
> a strange case and there was some discussion previously about separating
> the v3 portal vs. cursor namespaces anyway.

OK, if everybody is saying "dont worry", I'll switch it to use atStart.

Best Regards, Simon Riggs