pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feed"Cannot" vs "could not"
3+ messages / 2 participants
[nested] [flat]
* "Cannot" vs "could not"
@ 2020-03-19 15:57 Bruce Momjian <bruce@momjian.us>
2020-03-19 16:07 ` Re: "Cannot" vs "could not" Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Bruce Momjian @ 2020-03-19 15:57 UTC (permalink / raw)
To: pgsql-docs
We use "cannot" and "could not" quite often in source code and error
messages:
$ grep .. 'cannot' | wc -l
13180
$ grep ... 'could not' | wc -l
12149
I noticed it by looking for errors about parsing in our /bin tools:
src/pl/plperl/ppport.h: die "cannot parse version '$ver'\n";
src/pl/plperl/ppport.h: die "cannot parse version '$ver'\n";
src/bin/pg_upgrade/server.c: pg_fatal("could not parse version file \"%s\"\n", cluster->pgdata);
This web page explains the difference well, i.e., "cannot" is present
tens, "could not" is past tense:
https://www.englishforums.com/English/CannotVsCouldNot/bhprvk/post.htm
Is there any sense that we should have more consistency in our message
wording?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: "Cannot" vs "could not"
2020-03-19 15:57 "Cannot" vs "could not" Bruce Momjian <bruce@momjian.us>
@ 2020-03-19 16:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-03-19 16:37 ` Re: "Cannot" vs "could not" Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2020-03-19 16:07 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-docs
Bruce Momjian <bruce@momjian.us> writes:
> We use "cannot" and "could not" quite often in source code and error
> messages:
Yup.
> Is there any sense that we should have more consistency in our message
> wording?
There is specific guidance about it in our error message style guide:
https://www.postgresql.org/docs/devel/error-style-guide.html
(see under "Present vs. Past Tense"). I believe we largely conform
to that guideline, though of course exceptions sneak in from time
to time.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: "Cannot" vs "could not"
2020-03-19 15:57 "Cannot" vs "could not" Bruce Momjian <bruce@momjian.us>
2020-03-19 16:07 ` Re: "Cannot" vs "could not" Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-03-19 16:37 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 3+ messages in thread
From: Bruce Momjian @ 2020-03-19 16:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs
On Thu, Mar 19, 2020 at 12:07:35PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > We use "cannot" and "could not" quite often in source code and error
> > messages:
>
> Yup.
>
> > Is there any sense that we should have more consistency in our message
> > wording?
>
> There is specific guidance about it in our error message style guide:
>
> https://www.postgresql.org/docs/devel/error-style-guide.html
>
> (see under "Present vs. Past Tense"). I believe we largely conform
> to that guideline, though of course exceptions sneak in from time
> to time.
Oh, good. I remember we discussed this in the past, but didn't realize
we had written it down. Thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2020-03-19 16:37 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 15:57 "Cannot" vs "could not" Bruce Momjian <bruce@momjian.us>
2020-03-19 16:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-03-19 16:37 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox