Doc patch: replace 'salesmen' with 'salespeople'

On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker <ilmari@ilmari.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.

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 salesmen.id = accounts.sales_id);
+    (SELECT first_name, last_name FROM salespeople
+     WHERE salespeople.id = 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?

--
Daniel Gustafsson https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:

On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker <ilmari@ilmari.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").

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 salesmen.id = accounts.sales_id);
+    (SELECT first_name, last_name FROM salespeople
+     WHERE salespeople.id = 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.

- ilmari

On 25 Mar 2022, at 13:59, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker <ilmari@ilmari.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 salesmen.id = accounts.sales_id);
+    (SELECT first_name, last_name FROM salespeople
+     WHERE salespeople.id = 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 https://vmware.com/