Re: trailing comment ghost-timing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: trailing comment ghost-timing
Date: 2013-12-24 14:59:23
Message-ID: 30685.1387897163@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2013-12-24 15:17:49 Re: varattno remapping
Previous Message Erik Rijkers 2013-12-24 14:27:54 Re: trailing comment ghost-timing