Re: Doc patch: replace 'salesmen' with 'salespeople'
От | Daniel Gustafsson |
---|---|
Тема | Re: Doc patch: replace 'salesmen' with 'salespeople' |
Дата | |
Msg-id | F6D27278-792D-42A2-AC65-F381BBF4F75C@yesql.se обсуждение исходный текст |
Ответ на | Re: Doc patch: replace 'salesmen' with 'salespeople' (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>) |
Список | pgsql-hackers |
> 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/
В списке pgsql-hackers по дате отправления: