psql small improvement patch
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t41631psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 12:27 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t41631_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t41631_1 && git checkout t41631_1Patchset v1 (message #1) is on t41631_1
Hi, Hackers.
I propose a small improvement to the psql command.
Currently, psql's help/quit/exit command needs to start from the first position of the prompt.
For example, if you write a command after a space, the continuation prompt
(PROMPT2) is displayed.
---
postgres=> \set PROMPT2 'continue=>'
postgres=> <SPACE>help
continue=>
---
The attached patch allows the command to be executed ignoring leading white spaces.
Regards,
Noriyoshi Shinoda
On 12/7/19 5:23 AM, Shinoda, Noriyoshi (PN Japan A&PS Delivery) wrote:
Hi, Hackers.
I propose a small improvement to the psql command.
Currently, psql's help/quit/exit command needs to start from the first position of the prompt.
For example, if you write a command after a space, the continuation prompt
(PROMPT2) is displayed.---
postgres=> \set PROMPT2 'continue=>'
postgres=> <SPACE>help
continue=>
---The attached patch allows the command to be executed ignoring leading white spaces.
Thank you for the patch. I took a look, and have two concerns.
The smaller concern is that psql uses isspace() to determine whether a
character is whitespace in the current locale, so instead of using
strspn(line, " \t") you might want to use isspace() and be consistent.
On the other hand, there is precedent in other files for what you are
doing, such as in src/fe_utils/print.c:
/* is string only whitespace? */
if ((*ptr)[strspn(*ptr, " \t")] == '\0')
My larger concern is that people may be using space before a command
word to avoid having it be interpreted as a command. Take for example
the following contrived psql interaction:
mark=# create table help (str text);
CREATE TABLE
mark=# insert into help (str) values ('foo');
INSERT 0 1
mark=# select * from
mark-# help
mark-# where str is not null;
str
-----
foo
(1 row)
In the current unpatched psql, if I don't indent the second line, I
get cruft in the output:
mark=# select * from
mark-# help
Use \? for help or press control-C to clear the input buffer.
mark-# where str is not null;
str
-----
foo
(1 row)
Patching psql as you propose would result in that cruft whether or
not I indent the second line. We would need to consider if that
behavior change is going to cause more problems for users than your
patch is worth. How common is this problem you are trying to fix?
--
Mark Dilger
"Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi.shinoda@hpe.com> writes:
I propose a small improvement to the psql command.
Currently, psql's help/quit/exit command needs to start from the first position of the prompt.
The attached patch allows the command to be executed ignoring leading white spaces.
Please read the (very long) thread in which this behavior was designed:
/messages/by-id/CACYgWUnvCSeiFXyw9+VqHVAd+fUxYhsrGxacRGJao63gznV9UQ@mail.gmail.com
Allowing whitespace before the special command was part of the design
early on, eg my proposal at
/messages/by-id/30157.1513058300@sss.pgh.pa.us
but we eventually decided not to, see further down at
/messages/by-id/20180125204630.GA27619@momjian.us
If you want to reverse that decision you need to present cogent arguments
why, not just send in a patch.
regards, tom lane
Thank you very much for your comments.
I seem to have thought easily. I will reconsider.
Regards.
-----Original Message-----
From: Mark Dilger [mailto:hornschnorter@gmail.com]
Sent: Sunday, December 8, 2019 12:20 AM
To: Shinoda, Noriyoshi (PN Japan A&PS Delivery) <noriyoshi.shinoda@hpe.com>; pgsql-hackers@lists.postgresql.org
Subject: Re: psql small improvement patch
On 12/7/19 5:23 AM, Shinoda, Noriyoshi (PN Japan A&PS Delivery) wrote:
Hi, Hackers.
I propose a small improvement to the psql command.
Currently, psql's help/quit/exit command needs to start from the first position of the prompt.
For example, if you write a command after a space, the continuation
prompt
(PROMPT2) is displayed.---
postgres=> \set PROMPT2 'continue=>'
postgres=> <SPACE>help
continue=>
---The attached patch allows the command to be executed ignoring leading white spaces.
Thank you for the patch. I took a look, and have two concerns.
The smaller concern is that psql uses isspace() to determine whether a character is whitespace in the current locale, so instead of using strspn(line, " \t") you might want to use isspace() and be consistent.
On the other hand, there is precedent in other files for what you are doing, such as in src/fe_utils/print.c:
/* is string only whitespace? */
if ((*ptr)[strspn(*ptr, " \t")] == '\0')
My larger concern is that people may be using space before a command word to avoid having it be interpreted as a command. Take for example the following contrived psql interaction:
mark=# create table help (str text);
CREATE TABLE
mark=# insert into help (str) values ('foo');
INSERT 0 1
mark=# select * from
mark-# help
mark-# where str is not null;
str
-----
foo
(1 row)
In the current unpatched psql, if I don't indent the second line, I get cruft in the output:
mark=# select * from
mark-# help
Use \? for help or press control-C to clear the input buffer.
mark-# where str is not null;
str
-----
foo
(1 row)
Patching psql as you propose would result in that cruft whether or not I indent the second line. We would need to consider if that behavior change is going to cause more problems for users than your patch is worth. How common is this problem you are trying to fix?
--
Mark Dilger
On Sat, Dec 7, 2019 at 12:58:12PM -0500, Tom Lane wrote:
"Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi.shinoda@hpe.com> writes:
I propose a small improvement to the psql command.
Currently, psql's help/quit/exit command needs to start from the first position of the prompt.
The attached patch allows the command to be executed ignoring leading white spaces.Please read the (very long) thread in which this behavior was designed:
/messages/by-id/CACYgWUnvCSeiFXyw9+VqHVAd+fUxYhsrGxacRGJao63gznV9UQ@mail.gmail.com
Allowing whitespace before the special command was part of the design
early on, eg my proposal at/messages/by-id/30157.1513058300@sss.pgh.pa.us
but we eventually decided not to, see further down at
/messages/by-id/20180125204630.GA27619@momjian.us
If you want to reverse that decision you need to present cogent arguments
why, not just send in a patch.
Do we need a C comment to document why no whitespace is allowed
before it?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Bruce Momjian <bruce@momjian.us> writes:
Do we need a C comment to document why no whitespace is allowed
before it?
Probably, else we may not remember next time somebody wants to
change it.
regards, tom lane
On Sat, Dec 21, 2019 at 03:42:21PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Do we need a C comment to document why no whitespace is allowed
before it?Probably, else we may not remember next time somebody wants to
change it.
Done, applied to master only.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +