"Cannot" vs "could not"
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 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 +
Re: "Cannot" vs "could not"
Bruce Momjian 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
Re: "Cannot" vs "could not"
On Thu, Mar 19, 2020 at 12:07:35PM -0400, Tom Lane wrote: > Bruce Momjian 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 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 +
Re: explanation for random_page_cost is outdated
On Thu, Feb 27, 2020 at 02:48:44PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/runtime-config-query.html > Description: > > Explanation for random_page_cost is rather outdated, because it did only for > case of mechanical hdd. But all modern database servers, which I know, made > upon SSD. Do or not do default value for random_page_cost equal to 1 is the > question, but, IMHO, at list in the documentation about random_page_cost > need to add in a speculation about SSD. > > It's important because a business programming now is mostly web programming. > Most database is poorly designed by web programmer, tables looked like a > primary key and a huge json (containing all) with large gin index upon it. > Now I am seeing a table with a GIN index 50% of the table size. The database > is on SSD, of cause. With default random_page_cost=4 GIN index don't used > by planner, but with random_page_cost=1 the result may be not excellent, but > acceptable for web programmers. Does this sentence in the random_page_cost docs unclear or not have enough visibility: https://www.postgresql.org/docs/12/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS Storage that has a low random read cost relative to sequential, e.g. solid-state drives, might also be better modeled with a lower value for random_page_cost. -- Bruce Momjian 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 +
