Нефига себе, открыл вику, а там про постгрис вон что

пишут.
Это что, в Postgres хранимки можно на Java писать?)))

Может быть это про хранимые процедуры имел в виду автор?

https://tada.github.io/pljava/use/hello.html не, реально!

На JAVA не пробовал, а на питоне запросто

я смотрю там и php есть, и js... Интересно, если Java код решит в файл писать инфу какую-то, при вызове из postgres'а, это будет работать? По идее, никаких проблем не должно быть, т.к для исполнения java кода нужно запустить jvm процесс, который никак не будет связан с postgres, а значит у него будут свои ограничения - если никто писать не запретил, пишет... Можно же и вычисления распараллелить...rowset передал в java метод, он быстренько посчитал что-нибудь и вернул результат... или сформировал красивый Xls отчёт, например, используя Java API и положив его на ftp....

а еще, java может создать коннешен к БД, вытащить данные, быстро общитать и положить их обратно и это, невероятно

это другое. Для таких целей нужно асинхронный драйвер юзать. P.S но попытка троллинга защитана:) P.P.S хотя фиг вам, не защитана. Вы не поняли же фишки...))

то есть разница только в том, что обычно java —> db, а так db —> java, но при этом никаких преимуществ (ну кроме того что управляющий код в БД, а значит там и бизнес логика будет) если бы это было круто и инновационно, сейчас все круды делались бы как PL/Java, PL/Python, но этого не происходит, к счастью.

Да не, я не к тому, что давайте ломанемся писать на pl/java. Тоже считаю, что это не нужно, т.к огромное число dbd знают pl/sql, а не какой то там pl/java :) Просто, допустим есть задача получения большого красивого отчета в Excel. Какие варианты? Можно запустить в процессе java поток, взять из пула свободный коннект и выполнить запрос. Что в таком случае будет? Висит коннект, висит поток. А зачем нам это безобразие? Окей, идём дальше, чтобы не висел поток и коннект. Тогда, надо, чтобы база положила куда то итог, чтобы потом его можно было обработать. Ну, окей. Но появляются какие то промежуточные итоги полученных данных, которые затем опять надо хендлить. И тут 2 варианта: или асинхронный драйвер или написать на java функцию генерации отчёта и складирования его на ftp, которая автоматом вызовется, как только будет получен result set или его часть, например. Таким образом не будет ненужного промежуточного хранения данных где то + мы не будем держать коннект к базе и поток на уровне java в холостую.

дабы не разводить холивар, я просто скажу: я бы не пошел дальше =)

А как вы решаете задачу, если например минут 5 сборка данных для отчёта идёт, если не через асинхронный драйвер? Промежуточные результаты храните?

ETL —> elastic search. аналитику делать на горячей базе - такое себе

OLAP? Cognos? BI? ну вообщем точно не запросами в БД

Сейчас пробуем Clickhouse, Greenplum, я ещё хочу Couchbase попробовать.... :) Но вообще я про текущую реализацию в несколько ТБ у нас про Postgres говорил:) Вот ему тяжеловато olap на таких объёмах.

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

А что за асинхронный драйвер? Я например делаю коннект из Java к пг через какой-то jdbc, он не асинхронный? Если я например сделаю в джаве пять потоков, они не смогут параллельно подключиться что-ли?

Нет, он синхронный. Открыли коннект и пока БД не вернёт ответ, коннект занят. Ну и ваш поток в java тоже ждёт.

А нельзя как-то в Java приложении просто создать несколько экземпляров драйвера ?

Не, ну у вас 5 потоков то будут работать конечно, просто они откроют 5 коннектов, если когда новому потоку нужно выполнить операцию, а предыдущий коннект не вернулся в пул коннектов. То, о чем я писал, про асинхронный драйвер, это r2dbc

Спасибо запомню, мб пригодится

Ну r2dbc тащить туда, где он не нужен, точно не надо. К этому нужно прийти😊 Когда упретесь, как говорится, тогда усложнив систему будете его юзать, если других решений не найдёте.

Да я точно не упрусь, у меня пет проект, в нём постгрес как гаубица для стрельбы по мухе)))

это реактивный драйвер, не просто асинхронный, и он по скорости проигрывает jdbc брать только для задач стриминга и то, тут других решений полно прям на уровне расширений постгреса нормальный реактивный драйвер только один - vertx reactive sql driver, production ready а так, скоро лум залетит в джаву, второе дыхание для jdbc, вопрос окончательно закрыт будет (с альтернативами блокирующему драйверу)

Про vertx, вы имеете ввиду vertx reactive Postgres client?

да, это единственный продакшен реди драйвер-альтернатива jdbc

Ну они под капотом тоже юзают специфический драйвер https://github.com/mauricio/postgresql-async

нет, не юзают - https://github.com/eclipse-vertx/vertx-sql-client

Вы кидаете ссылку на клиентов, а я на драйвер, который используется под капотом у клиентов) это разные вещи

я вам кидаю ссылку, чтобы вы прочитали pom.xml и убедились, как вы не правы драйвер написан с нуля, никаких зависимостей нет то, что вы скинули, не имеет отношения к современному vertx driver

Ну jasync там? Новая версия mauricio

боже, нет, это разные драйверы, vertx driver с нуля написан - легко проверить по гитхаб ссылке и зависимостям в мэйвен модулях

Я с мобилы и сплю уже, а вы кидаете ссылки на сайты, где много текста😊 Киньте прямо ссылку на помник, в чем проблема? :)

давайте по-простому https://github.com/jasync-sql/jasync-sql - это порт драйвера маурисио его когда-то юзал вертикс драйвер старый - https://github.com/vert-x3/vertx-mysql-postgresql-client (в этом репозитории есть ссылка на новый уже) новый же - https://github.com/eclipse-vertx/vertx-sql-client написан с нуля https://github.com/eclipse-vertx/vertx-sql-client/blob/master/pom.xml https://github.com/eclipse-vertx/vertx-sql-client/blob/master/vertx-pg-client/pom.xml https://github.com/eclipse-vertx/vertx-sql-client/blob/master/vertx-sql-client/pom.xml

Ещё раз уточню - вы понимаете разницу между драйвером и клиентом к базе данных? :)

да, вас не должно смузать название client у vertx, это не обертка над чем бы то ни было, полностью самостоятельная реализация протокола postgres

Да вот как раз нет:)

да, ссылки выше

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

Для начала, научитесь слушать собеседника и подтяните свои устаревшие знания. Я три раза сказал, что vertx sql client - это написанный с нуля альтернативный драйвер. Никаких оберток над jasync или другими вещами. Видно же, вы не работали с ним, кидаете старые ссылки из гугла. И остерегайтесь советовать использовать то, что не использовали сами, у r2dbc куча подводных. Доброй ночи.

Непонятно, почему PL/COBOL не добавлен!