Skip site navigation (1) Skip section navigation (2)

Re: The may/can/might business

From: Richard Troy <rtroy(at)ScienceTools(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The may/can/might business
Date: 2007-02-01 21:05:55
Message-ID: Pine.LNX.4.33.0702011303530.23745-100000@denzel.in (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 1 Feb 2007, Bruce Momjian wrote:
> From: Bruce Momjian <bruce(at)momjian(dot)us>
> Tom Lane wrote:
> > 3606c3606
> > <                    errmsg("aggregate function calls cannot be nested")));
> > ---
> > >                    errmsg("aggregate function calls may not be nested")));
> >
> > I don't think that this is an improvement, or even correct English.
> >
> > You have changed a message that states that an action is logically
> > impossible into one that implies we are arbitrarily refusing to let
> > the user do something that *could* be done, if only we'd let him.
> >
> > There is relevant material in the message style guidelines, section
> > 45.3.8: it says that "cannot open file "%s" ... indicates that the
> > functionality of opening the named file does not exist at all in the
> > program, or that it's conceptually impossible."
>
> Uh, I think you might be reading the diff backwards.  The current CVS
> wording is "cannot".

No, Bruce, he got it exactly right: "cannot" indicates, as Tom put it,
"logical impossibility," whereas "may not" suggests that something could
happen but it's being prevented. His parsing of the english was spot-on.

RT


-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/


In response to

Responses

pgsql-hackers by date

Next:From: Jeremy DrakeDate: 2007-02-01 21:20:18
Subject: writing new regexp functions
Previous:From: Tom LaneDate: 2007-02-01 21:04:33
Subject: Re: The may/can/might business

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group