Given a relation POSITION (Posting-No, Skill), the query to retrieve all…

Concept: comparing tuples of a relation with other tuples of the same relation requires a self-join — the relation is named twice in the FROM clause under two different aliases, so each alias ranges over the rows independently and one output row can carry values drawn from two different tuples.

Concept: an unrestricted self-join yields ordered pairs, keeping the pairing of a tuple with itself and keeping both orders of any two tuples. An equality predicate on the paired attribute retains only the pairings whose two values are the same; a strict-inequality predicate on that attribute discards the pairing of a value with itself and retains one of the two orders, which is what makes every unordered pair of distinct values appear once.

Application to POSITION (Posting-No, Skill):

1. The FROM clause naming position twice, as p1 and p2, forms the Cartesian product of the relation with itself, so every tuple is paired with every tuple.

2. The condition on skill keeps only those pairings whose two tuples record the same skill.

3. The strict comparison on posting-no then decides which pairings survive: a value is never less than itself, so a tuple paired with itself is discarded, and of the two orders of two different posting numbers exactly one satisfies the comparison.

4. The select list projects the two posting numbers of each surviving pairing as one two-column row.

Hence the required query is:

Select p1.posting-No, p2.posting-No
from position p1, position p2
where p1.skill = p2.skill
and p1.posting-No < p2.posting-No

Cross-check on a skill group holding the posting numbers 10, 20 and 30 — the same three tuples under each different WHERE clause:

Only the strict-inequality form lists each pair of distinct posting numbers exactly once, which is what "all distinct pairs" requires.

Two notes on the source wording. The attribute name Posting-No is written unquoted here, as in the original paper; under strict SQL identifier rules a hyphenated name would have to be delimited, and that applies equally to all four queries, so it does not change which of them answers the question. Also, the projection is not deduplicated, so under bag semantics two postings that share two skills would be listed once per shared skill; adding SELECT DISTINCT removes that repetition. Neither point changes the comparison above, because discarding the pairing of a posting number with itself and keeping one of the two orders is achieved by the strict-inequality predicate on posting-no.