0011786: consider returning total number of results in paginated responses

ID	Project	Category	View Status	Date Submitted	Last Update
0011786	Taler	other	public	2026-09-10 13:33	2026-09-19 13:23

Reporter	Florian Dold	Assigned To		Resolution deadline
Implementer		Reviewer
Release signed by		Deployed by
Verifier		Communicator
Data protection authority notification required	No
CSIRT notification required	No
Estimated effort (hours)		Actual effort (hours)	0
Fast-track	No
Work package	none
Priority	normal	Severity	feature	Reproducibility	have not tried
Status	acknowledged	Resolution	open
Target Version	Someday

Summary	0011786: consider returning total number of results in paginated responses
Description	It's a pretty common pattern to show the total number of results in paginated responsed. I think that where we can cheaply return this information, we should! This first needs a spec, i.e. we need to agree on some common name(s) for field(s) in various APIs.
Tags	No tags attached.

Date Modified	Username	Field	Change
2026-09-10 13:33	Florian Dold	New Issue
2026-09-10 13:33	Florian Dold	Status	new => assigned
2026-09-10 13:33	Florian Dold	Assigned To	=> Christian Grothoff
2026-09-18 21:12	Christian Grothoff	Note Added: 0030006
2026-09-18 21:13	Christian Grothoff	Severity	minor => feature
2026-09-18 21:13	Christian Grothoff	Status	assigned => acknowledged
2026-09-18 21:13	Christian Grothoff	Target Version	1.8 => Someday
2026-09-19 13:23	Christian Grothoff	Assigned To	Christian Grothoff =>

Christian Grothoff 2026-09-18 21:12 manager ~0030006	In PostgreSQL, the complexity of: SELECT count() FROM table_name; is generally O(n), where n is the number of rows in the table. pg_class.reltuples is an O(1) approach to get an approximation*, but probably not good enough. So adding this would require a new table (!) where we would have to track the counter and UPDATE on every INSERT/DELETE. Doable, but painful and I'm not convinced worth the overhead...