У SERIAL есть есть ещё несколько недостатков.
1. При удалении записей в нумерации возникают разрывы. Всё бы ничего, но читайте 2.
2. Счётчик будет сбрасываться при достижении максимально разрешённого для данного поля значения. Т.е. на таблицах с очень большим количеством записей или где часто используется вставка-удаление записей возможна ситуация, когда значение счётчика будет сброшено в 1 по достижении максимального значения для данного типа. К чему это может привести сказать трудно, но в большинстве случаев ни к чему хорошему 

Когда я только начинал работать с SQL и изучать SQL СУБД один хороший человек (Денис Галицкий) подсказал мне очень интересное и хитрое решение для обеспечения беспрерывной нумерации.
1. Создаётся таблица где для нумерации используется скажем INTEGER поле ID
3. На таблицу навешиваются два триггера - на удаление и на вставку
4. Создаётся вспомогательная таблица для хранения ID
5. При удалении триггер запускает функцию, которая берёт ID из удаляемой записи и сохраняет его значение во вспомогательной таблице
6. При вставке новой записи триггер запускает функцию, которая сперва просматривает ID во вспомогательной таблице с наименьшим номером и если он найден - возвращает его. Если вспомогательная таблица пуста, то значение ID берётся как максимальное значение ID из основной таблицы + 1
7. Чтобы всё время не дёргать max для вычисления максимальных значний - можно сохранять это значение при вставке в ещё одну вспомогательную таблицу.

На первый взгляд решение выглядит громозким. Однако для больших таблиц оно очень даже оправдано, не говоря уже что позволяет избежать множества проблем в будущем.

Только что заметил интересную вещь, связанную с SERIAL и наследованием, которую стоит принять во внимание - так как она, возможно, будет иногда полезна.
Создадим простую таблицу такого вот вида:

CREATE TABLE test1 (
	id serial);

При этом будет автоматом создана последовательность test1_id_seq. Далее, унаследуем от этой таблицы вторую таблицу, даже не добавляя в неё других полей:

CREATE TABLE test2
	INHERITS (test1);

О удивление! Оказывается, это не совсем новый объект; обе таблицы - и родитель, и потомок - используют общий генератор последовательности. Более того, все таблицы, участвующие в такого рода наследовании, будут использовать общий объект SEQUENCE, созданный их общим прародителем.
Таким образом, в случае, если не требуется непосредственная настройка генератора последовательности для отдельных таблиц, то поле счетчика вполне достаточно создать один раз для его дальнейшего автоматического использования.

Ещё одна интересная вещь - используя pgAdmin III, я обнаружил, что при задании поля с псевдотипом SERIAL автоматически создается последовательность с "большим" запасом, аналогичная псевдотипу BIGSERIAL.
Однако есть ли в этом смысл, если реальный тип, присваиваемый полю счетчика - integer и большие значения счетчика все равно не влезут в это поле? Осталось спросить об этом у разработчиков 

Я не вижу ничего страшного, ни в появлении "дырок", ни в сбросе индекса в минимальное значение при cycle.
nextval работает вполне четко.
Если при увеличении счетчика на 1 окажется, что в таблице уже есть запись с таким номером (по крайней мере для первичного ключа, где автоматически требуется уникальность), счетчик будет увеличиваться, пока не найдется пустая запись. Если такая не найдется - будет сообщение об ошибке.

Если не верите, создайте короткую последовательность cycle с верхним значением, например, 5. И поэкспериментируйте с добавлением и удалением записей. Проблема возникает только, если в последовательности нет "дырок".

Создавать какие-то вспомогательные таблицы для хранения индексов удаленных полей - странно. Все отлично работает стандартными средствами, без всяких нарушений целостности.

с помощью последовательностей можно организовать любую нужную нумерацию записей. Используйте во всех категорях одну последовательность и совпадение индексов в принципе будет невозможным.