Re: message style

While reading another thread that attempted to link to this email, I
discovered that this email never made it to the list archives. I am
trying again.

On Tue, Apr 30, 2019 at 12:05 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Apr 30, 2019 at 10:58 AM Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > My problem here is not really the replacement of the name to %s, but the
> > "may not be" part of it. We don't use "may not be" anywhere else; most
> > places seem to use "foo cannot be X" and a small number of other places
> > use "foo must not be Y". I'm not able to judge which of the two is
> > better (so change all messages to use that form), or if there's a
> > semantic difference and if so which one to use in this case.
>
> The message style guidelines specifically discourage the use of "may",
> IMHO for good reason. "mumble may not be flidgy" could be trying to
> tell you that something is impermissible, as in "the children may not
> run in the house." But it could also be warning you that something is
> doubtful, as in "the children may not receive Easter candy this year
> because there is a worldwide chocolate shortage." Sometimes the same
> sentence can be read either way, like "this table may not be
> truncated," which can mean either that TRUNCATE is going to fail if
> run in the future, or that it is unclear whether TRUNCATE was already
> run in the past.
>
> As far as "cannot" and "must not" is murkier, but it looks to me as
> though we prefer "cannot" to "must not" about 9:1, so most often
> "cannot" is the right thing, but not always. The distinction seems to
> be that we use "cannot" to talk about things that we are unwilling or
> unable to do in the future, whereas "must not" is used to admonish the
> user about what has already taken place. Consider:
>
> array must not contain nulls
> header key must not contain newlines
> cast function must not return a set
> interval time zone \"%s\" must not include months or days
> function \"%s\" must not be SECURITY DEFINER
>
> vs.
>
> cannot drop %s because %s requires it
> cannot PREPARE a transaction that has manipulated logical replication workers
> cannot reindex temporary tables of other sessions
> cannot inherit from partitioned table \"%s\"
>
> The first set of messages are essentially complaints about the past.
> The array shouldn't have contained nulls, but it did! The header key
> should not have contained newlines, but it did! The cast function
> should not return a set, but it does! Hence, we are sad and are
> throwing an error. The second set are statements that we are
> unwilling or unable to proceed, but they don't necessarily carry the
> connotation that there is a problem already in the past. You've just
> asked for something you are not going to get.
>
> I think principle that still leaves some ambiguity. For example, you
> could phrase that second of the "cannot" message as "must not try to
> PREPARE a transaction that has manipulated logical replication
> workers." That's grammatical and everything, but it sounds a bit
> accusatory, like the user is in trouble or something. I think that's
> probably why we tend to prefer "cannot" in most cases. But sometimes
> that would lead to a longer or less informative message. For example,
> you can't just change
>
> function \"%s\" must not be SECURITY DEFINER
>
> to
>
> function \"%s\" can not be SECURITY DEFINER
>
> ...because the user will rightly respond "well, I guess it can,
> because it is." We could say
>
> can not execute security definer functions from PL/Tcl
>
> ...but that sucks because we now have no reasonable place to put the
> function name. We could say
>
> can not execute security definer function \"%s\" from PL/Tcl
>
> ...but that also sucks because now the message only says that this one
> particular security definer function cannot be executed, rather than
> saying that ALL security definer functions cannot be executed. To
> really get there, you'd have to do something like
>
> function "\%s" cannot be executed by PL/Tcl because it is a security
> definer function
>
> ...which is fine, but kinda long. On the plus side it's more clear
> about the source of the error (PL/Tcl) than the current message which
> doesn't state that explicitly, so perhaps it's an improvement anyway,
> but the general point is that sometimes I think there is no succinct
> way of expressing the complaint clearly without using "must not".
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company