Лично я этот url руками делаю обычно. И кажется, что с этими url и параметрами подключений вообще какой-то бардак.

Для меня тоже странный вопрос "получить"

так URL для каждого языка будет отличатся, и какой тогда вообще смысл

позвольте уточнить - какого языка?

локали?

для java, отличается как минимум

Для реализации адаптера?

как может UNIFORM resource locator отличаться для Java?
стало интересно

А почему бы ни добавить хинты, которые планировщик не будет напрямую использовать, а хотя бы сравнивать с тем, что у него без хинтов получается, и брать лучший вариант их 2-ух (с хинтами и без)?

Хмм... потому что это совершенно бесполезно почти во всех случаях?
Вы представляете, как работает планирование запросов в общем (в т.ч. в других СУБД) и как в него встраиваются "обычные" hints? Если да, то почему Вам кажется, что "брать лучший вариант их 2-ух" вообще может работать?
Если же Вы имеете в виду какие-то необычные hints — то какие?

И, опять-таки: "If you have an idea that avoids the problems that have been observed with other hint systems, that could lead to valuable discussion." А Ваше предложение как позволяет избежать этих проблем?

На самом деле -- хинты для postgres давно есть, https://osdn.net/projects/pghintplan/

Кажэтся, дажэ работают (хотя я и большой любитель хинтов -- но по факту во всех проектах пока что изнасилование costs и прочих статистик вполне давало результат, так что заморачиваться сборкой расшырения мне всегда было лень).

Или, замечу, не изнасилование костов, а переписывание запроса на несколько разделённых барьером этапов в нужной мне последовательности.

В операторах, которые используют символ ?, этот символ необходимо задваивать.

Нет, не представляю, как встраиваются хинты.

На мой взгляд хинт "диктует", а я хотел бы, чтобы хинт подсказывал на альтернативный план, а что выбрать пусть PG разбирается.

Ну вот посмотрите хотя бы на https://t.me/pgsql/310070 — встраиваются хинты обычно как-то так.
Суть большинства "обычных" hints в том, что они искусственно ограничивают выбор планировщика (как "наши" enable_*).
Естественно, такое (в т.ч. pg_hint_plan) в core PostgreSQL не нужно, по указанным в приведённой ссылке причинам.

> чтобы хинт подсказывал на альтернативный план

Как "подсказывал", т.е. почему PostgreSQL должен выбрать его вместо альтернативного?

Да-да, я как раз разглядываю его сейчас.
Выглядит ужасно и да, очень похоже на enable_*.

Я имел ввиду не "подсказывал", а "предлагал рассмотреть".

Соответственно вариант с подсказкой PG рассматривает и подсчитывает costs там. Потом смотрит на costs с подсказкой и на costs без подсказки и выбирает лучший.

Имеет смысл видимо для запросов с большим количеством join-ов. В подсказке ещё нужно дать возможность указывать, что первым join-ить, а что потом.

С малым числом join-ов PG итак справляется.

> Имеет смысл видимо для запросов с большим количеством join-ов.

Ну вот я поэтому и написал "это совершенно бесполезно почти во всех случаях".
А hints обычно хотят использовать совсем с другими целями. ;)

Понятно, т.е. редкие use case-ы как бы не рассматриваются?

Так, что никакого общего стандарта на схемы отличные от http(s), ftp, gopher и может быть ещё парочки просто не оформили. Для jdbc есть свой формат "URL" (вообще, это называется connection string), в котором схема определяет то, какой драйвер использовать, а остальное зависит от драйвера. Но не удивлюсь, если под другой язык строка подключения к бд строится иначе, либо, при схожих принципах, префиксы, определяющие СУБД, другие.

Рассматриваются, но анализ выгод и затрат очевидно приводит к We are not interested in implementing hints in the exact ways they are commonly implemented on other databases. Proposals based on "because they've got them" will not be welcomed.
И это же общий принцип, согласно которому отвергаются все подобные "улучшения" планировщика.