The highest voted answer in the question linked to by the other answer suggests collapsing all the page links into an input field. I've seen this, but scrolling a list and clicking a page number is a mouse-oriented activity, so I've never been inclined to switch to the keyboard to enter a page number. Perhaps the input could be a super-input that takes text or brings up a panel with page links (like most date field inputs these days), but I still think users wouldn't really know to expect anything better than having to type if they click on the box.
I prefer to use smart truncation to display the most helpful page links. In other words, I show the first 3, ...
, the current page with a padding of 3 (3 on either side), another ...
, then the last 3. With a lot of pages, the links above the list look like this (the mouse is hovering over 56):

Below the list, I provide all links:

That would still be ridiculous to do if you had more than a couple hundred pages, but you could still provide more context on the bottom than on the top (increase the context of the current page to 100 or more).
Some other things to remember:
- Use nice URLs:
/myapp/mylist/16
- Maybe you don't need pagination at all ("Show more..." or other endless list solutions). In this case, a user uses sorting or filtering/searching to jump to data that is far down the list.
- Don't take up space with
First
/Last
links if you already have a 1
and a ...[n]
, it's redundant and therefore not only space-wasting but also possibly confusing.
- If you were feeling inventive, the
...
could gain a box on hover and you could make it a button to bring up "more" pages in that range.
- You can always add a "Jump to: " quick input form next to your page links.