Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Implement pagination for [development collection] with [chosen sort fields]. Define a unique total ordering using an explicit tie-breaker and state how nulls and direction are handled. Choose whether traversal represents a fixed snapshot or a live collection; describe what concurrent inserts, updates, and deletions mean under that choice. If using a cursor, bind it to the sort and filter contract and validate incompatible or malformed cursors. Create fixtures with tied primary sort values and more than two pages. Walk forward, resume from a saved cursor, and mutate the fixture between page requests. Compare returned IDs with the written contract rather than assuming every live traversal must return a frozen set. Verify no accidental repetition at page boundaries for the stable fixture. Report result correctness separately from query performance and avoid promising that a cursor alone freezes the dataset.Make this prompt yours
Use for feeds, exports, and administrative lists. Unique ordering is necessary for predictable subsets, but concurrency still needs an explicit policy.
You might also hear
- keyset pagination
- stable ORDER BY
- cursor tie breaker
- live pagination
- snapshot traversal
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. PostgreSQL requires a unique ordering for predictable subsets; a cursor does not freeze mutable data, as the live/snapshot contract explicitly recognizes.