Re: trailing comment ghost-timing

Andres Freund <andres@2ndquadrant.com> writes:
> Maybe I am thinking to technical here, but why would that be a good
> idea? After all, the comment will have triggered sending a statement to
> the server and waiting for the result. The user might want to know about
> that.

I agree; if we triggered a server operation, we should report a timing.
Pretending we did not isn't a good solution.

The real question is whether we shouldn't suppress the whole PQexec.
I believe this is very closely related to the question of what we do
with a comment preceding the next command.  Try this experiment:

regression=# set log_statement = 'all';
SET
regression=# /* block comment here */
regression-# select 2+2;?column? 
----------       4
(1 row)

regression=# -- dash comment here
regression=# select 3+3;?column? 
----------       6
(1 row)

and then look in the postmaster log:

LOG:  statement: /* block comment here */       select 2+2;
LOG:  statement: select 3+3;

This is inconsistent, IMO.  I think if we were to fix things so that
leading block comments were dropped the same way -- comments are, that
would also take care of the behavior complained of in this thread.
There's been some previous discussion of this point, I think.

A related issue is that psql suppresses -- comments after the start of
the SQL statement as well as before it.  I think that this is probably not
such a good idea anymore; it has the potential at least to screw up
psql's reporting of error locations.  I think what would likely be the
ideal behavior is to drop all leading lines containing only
whitespace/comments, but once we identify the "first line of the
statement", transmit verbatim up till the closing semicolon.

Fun corner case:
   /* block comment      here */ SELECT ...

If we try to strip this comment we're definitely going to have issues with
error cursor positions.  So probably the way it will have to work is to
make a check at each end-of-line about whether we are outside any block
comment and haven't seen any SQL token yet, and flush the query collection
buffer if so.
        regards, tom lane