.TH Frame
.PP
Aka limit/offset
.SH Signature
.PP
.RS
.nf
frame(operand: Relation, order: Ordering, offset: Integer, limit: Integer) -> Relation
.fi
.RE
.SH Examples
.PP
.RS
.nf
frame(suppliers, [:status, :sid], 0, 3)
.fi
.RE
.PP
.RS
.nf
frame(suppliers, [[:status, :asc], [:sid, :desc]], 1, 2)
.fi
.RE
.SH Description
.PP
Computes a relation by restricting the tuples of \fB\fCoperand\fR to a particular
frame. This frame can be easily remembered through the "skip \fB\fCoffset\fR,
take \fB\fClimit\fR" mnemonic mean, provided \fB\fCorder\fR is a total order.
.PP
Formally, the frame is defined by those tuples whose ranking according to
\fB\fCorder\fR is such that \fB\fCoffset <= rank < limit\fR\&. In other words, this
operator is actually equivalent to the following definition:
.PP
.RS
.nf
def frame(operand, order, offset, limit)
  allbut(
    restrict(
      rank(operand, order, :rank),
      lte(offset, :rank) & lt(:rank, offset+limit)),
    [:rank])
end
frame(suppliers, [:city, :sid], 2, 3)
.fi
.RE
.PP
As of current Alf version, for this operator to be semantically sound and
deterministic, \fB\fCorder\fR MUST be a total order, that is, it must at least
cover a candidate key. As of current Alf version, no error is raised if
this is not the case but that might change in future versions.
.SH Implementation notes
.PP
Contrary to the longer expression shown above, this operator compiles to
\&'efficient' SQL (rank does not, so far) at the cost of having to provide a
total order.
.PP
As the result is a relation and relations are not ordered by definition,
the order in which tuples can be observed in the result (e.g. through
explicit tuple iteration, casting to an array, json encoding) is NOT
guaranteed to follow \fB\fCorder\fR\&.