From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Doc patch: replace 'salesmen' with 'salespeople' |
Date: | 2022-03-24 20:40:11 |
Message-ID: | 7924A395-67D0-4128-8693-D6E2A063092F@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
> 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-03-24 20:59:58 | Re: New Object Access Type hooks |
Previous Message | Andrew Dunstan | 2022-03-24 20:34:35 | Re: identifying unrecognized node type errors |