Tom Lane wrote:
> > 1. \p ignores the "previous buffer". Example:
>
> Yeah, I did that intentionally, thinking that the old behavior was
> confusing. We can certainly discuss it though. I'd tend to agree
> with your point that \p and \w should print the same thing, but
> maybe neither of them should look at the previous_buf.
>
> > 2. \r keeps the "previous buffer". I think it should clear it.
>
> I don't really agree with this. The fact that it used to clear both
> buffers was an implementation accident that probably nobody had even
> understood clearly. ISTM that loses functionality because you can't
> do \g anymore.
I don't have a strong opinion on \r. As a user I tend to use Ctrl+C
rather than \r for the edit in progress.
The documentation over-simplifies things as if there
was only one query buffer, instead of two of them.
\r or \reset
Resets (clears) the query buffer.
From just that reading, the behavior doesn't seem right when
we "clear the query buffer", and then print it, and it doesn't
come out as empty.
About \p alone, if it doesn't output what \g is about to run, I
think that's a problem because ISTM that it's the main use
case of \p
Following the chain of consistency, the starting point seems to be
that \g sends the previous query if the edit-in-progress input
buffer is empty, instead of saying, empty buffer = empty query,
so nothing to send.
Presumably the usage of issuing \g alone to repeat the last
query is well established, so we can't change it and need
to adjust the other commands to be as less surprising
as possible with our two buffers.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
