Хорошо бы было, если бы для каждого пользователя автоматически создавалась одноименная схема, например. И все объекты, создаваемые пользователем, помещались бы в этот namespace, а не в public.
Также полезной была бы возможность создавать роли, а не группы. И иметь возможность указывать роль при логине и менять в процессе работы.
Систему привилегий тоже не мешало бы расширить, на мой взгляд.
Cluster могла бы быть весьма полезной командой, если бы она означала то, что должна означать. Однократная организация таблицы по индексу не совсем то, что хотелось бы.

Это первое, что сразу пришло в голову.

2 Мимопроходящий:

Все же мне кажется, что роли являются более гибким средством, да и к стандарту ближе. %)

2 LeXa NalBat:

Может быть, это просто путаница терминов, но я привык под кластеризацией понимать физическое объединение строк одной или более таблиц с ключом, по которому производится кластеризация.
В случае с командой Cluster мы получаем таблицу, физически упорядоченную по значению индекса. Конечно, можно сказать, что таблица кластеризована по ключу индекса, я не спорю, и все же разница есть. В случае кластера индекс и сами данные расположены в одних и тех же блоках данных, и дополнительные операции чтения при получении данных не требуются, с другой стороны, упорядочение по индексу позволяет более эффективно использовать индекс в запросах на диапазон, например. Но полезность этого приема в Постгресе снижается тем, что при дальнейших модификациях таблицы эта организация нарушается.

2 Shweik:

Насколько я понимаю, управление физической структурой БД в Постгресе пока не предусмотрено.
Конечно, всякие табличные пространства и прочее было бы весьма полезно, хотя это приведет к усложнению самой СУБД и ее администрирования.
Если же говорить о команде Cluster, то это скорее улучшение кластеризованности индекса для данной таблицы, чем собственно кластеризация таблицы. То есть, данные располагаются на диске в том же порядке, что индексные ключи. Тем не менее, они продолжают находиться в разных блоках данных и, следовательно, доступ к строке по-прежнему требует две физических операции чтения.

Доступ к строке по индексу, в смысле.
Мечтается еще о пользовательских профилях, представлениях динамической активности базы данных, журналировании транзакций с возможностью восстановления на конкретный момент времени (наката после сбоя), горячем бэкапе базы данных в целом и отдельных табличных пространств с созданием согласованного бэкапа, архивировании транзакций, ну и "тогдалие".

2 Stas Tristan:

Если DBA (на любой СУБД) захочет посмотреть структуру базы, он это сделает. Сомневаюсь, что ему можно как-то помешать.