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 <robertmh...@gmail.com> wrote: > > On Tue, Apr 30, 2019 at 10:58 AM Alvaro Herrera > <alvhe...@2ndquadrant.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
