Horton

Thread

Commits

  1. doc: Make UPDATE FROM examples consistent

  2. Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...

  1. Doc patch: replace 'salesmen' with 'salespeople'

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2022-03-24T18:34:55Z

    Hi Hackers,

I just spotted an unnecessarily gendered example involving a 'salesmen'
table in the UPDATE docs. Here's a patch that changes that to
'salespeople'.

- ilmari

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

    Daniel Gustafsson <daniel@yesql.se> — 2022-03-24T20:40:11Z

    > 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/

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

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2022-03-25T12:59:35Z

    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

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

    Daniel Gustafsson <daniel@yesql.se> — 2022-03-26T20:08:38Z

    > 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/