Re: Doc patch: replace 'salesmen' with 'salespeople'

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Doc patch: replace 'salesmen' with 'salespeople'
Date: 2022-03-26 20:08:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 25 Mar 2022, at 13:59, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> wrote:
>>> I just spotted an unnecessarily gendered example involving a 'salesmen'
>>> table in the UPDATE docs. Here's a patch that changes that to
>>> 'salespeople'.
>> No objections to changing that, it's AFAICT the sole such usage in the docs.
> There's a mention of the travelling salesman problem in the GEQO docs
> (and one in the code comments), but that's the established name for that
> problem (although I do note the Wikipedia page says it's "also called
> the travelling salesperson problem").

I would be slightly worried about "git grep'ability" when changing such an
established name (even though the risk might be miniscule here). Unless it's
deemed controversial I would err on the side of caution and leave this alone.

>>> Update contact names in an accounts table to match the currently assigned
>>> - salesmen:
>>> + salespeople:
>>> <programlisting>
>>> UPDATE accounts SET (contact_first_name, contact_last_name) =
>>> - (SELECT first_name, last_name FROM salesmen
>>> - WHERE = accounts.sales_id);
>>> + (SELECT first_name, last_name FROM salespeople
>>> + WHERE = accounts.sales_id);
>> This example is a bit confusing to me, it's joining on accounts.sales_id to get
>> the assigned salesperson, but in the example just above we are finding the
>> salesperson by joining on accounts.sales_person. Shouldn't this be using the
>> employees table to keep it consistent? (which also avoids the gendered issue
>> raised here) The same goes for the second example. Or am I missing something?
> Yeah, you're right. The second section (added by Tom in commit
> 8f889b1083f) is inconsistent with the first half in both table and
> column names. Here's a patch that makes it all consistent, eliminating
> the salesmen references completely, rather than renaming them.

I think this is an improvement, both in language and content. The example does
show off a strange choice of schema but it's after all an example of syntax and
not data modelling. Barring objections I plan to go ahead with this.

Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-03-26 20:09:44 Re: pgsql: Add 'basebackup_to_shell' contrib module.
Previous Message Robert Haas 2022-03-26 20:03:24 Re: pgsql: Add 'basebackup_to_shell' contrib module.