Adrian Klaver schrieb am 15.01.2019 um 17:44:
>>> So we end up with something like this:
>>>
>>> select distinct on (C.contact_id) C.contact_id, C.lname, C.fname, C.direct_phone, O.org_name, A.next_contact
>>> from Contacts as C
>>> join Organizations as O on C.org_id = O.org_id
>>> join Activities as A on C.contact_id = A.contact_id
>>> where A.next_contact <= 'today'
>>> and A.next_contact > '2018-12-31'
>>> order by c.contact_id, a.next_contact DESC;
>>
>> And I've never liked this method (though I'm old and crotchety)....
>>
>
> What is the specific objection?
>
> To me:
>
> 1) Plus side. It saves an explicit sub-query
>
> 2) Minus side. It is not portable. But then complete portability is a unicorn in my opinion.
I think Ron was referring to the JOIN operator, rather than the DISTINCT ON
