"Sortable results" and "partial display of results" do not mix, unless the sort actually does sort against the full data set (such that a reverse sort goes and gets item Z etc, rather than just sorting whatever subset of items happen to already have loaded.) A table column sort that only sorts the currently-visible items, rather than the full data set, is worse than useless, because it produces misleading results for the users, and will have tons of undefinable corner cases. Here's one:
- Do a text search for "frog", it goes to the server and retrieves 100 frogs starting with "Alpha Frogs" and ending with the "Garbage Frogs"
- Click the column header to reverse sort. The list now begins with "Garbage Frogs" (because it was sorting only the already-loaded items).
- Change the text search to "frogs". This goes to the server and retrieves 100 names starting with "Zzyzx Frogs".
In other words the same search / sort can produce completely different results depending on in what order the user happened to perform the search. That, needless to say, is bad design.
(I've also seen even worse implementations of this, where a new text search simply discards any existing sort settings, which "solves" the inconsistent-results problem by making the sort settings useless -- now there's no way to get to the Zzyzx frogs other than by clicking through the entire set of pages until you find the end.)
So: if you're going to have paginated results, every sort operation must result in a server call so that the sorted, paginated results accurately reflect the available data -- "Only search against whatever I happen to already be looking at", which is what your proposed column sort would do, is not something anyone would set out to design on purpose. (Plenty of sites have, of course, wound up 'designing' it by accident. Those sites are bad, and they should feel bad, as the saying goes.)
The "undefined number of pages" question is much easier to answer: just "Show more" (or equivalent text), which appends to the existing table rather than dropping already loaded results.
The utility of a "page number" field is quite limited: what use is skipping ahead to page n unless I already know exactly how many items are in your database? It's really only useful when stepping back to previous "pages", which is unnecessary if you append new results rather than blowing away old ones.)