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

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Doc patch: replace 'salesmen' with 'salespeople'
Дата
Msg-id 7924A395-67D0-4128-8693-D6E2A063092F@yesql.se
обсуждение исходный текст
Ответ на Doc patch: replace 'salesmen' with 'salespeople'  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
Ответы Re: Doc patch: replace 'salesmen' with 'salespeople'  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
Список pgsql-hackers
> 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/




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: identifying unrecognized node type errors
Следующее
От: Andres Freund
Дата:
Сообщение: Re: New Object Access Type hooks