The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступен Pgfe 2, клиентский C++ API к PostgreSQL

18.04.2022 20:39

Опубликован первый стабильный выпуск Pgfe 2 (PostGres FrontEnd), продвинутого и многофункционального драйвера (клиентский API) для PostgreSQL, написанного на языке C++ и упрощающего работу с PostgreSQL в проектах на C++. Код проекта распространяется под лицензией Apache 2.0. Для сборки требуется компилятор с поддержкой стандарта C++17.

Основные возможности:

  • Соединение в блокирующем и неблокирующем режимах.
  • Обработка заранее подготовленных выражений (prepared statement) с позиционными и именованными параметрами.
  • Расширенная обработка ошибок с использованием исключений и кодов ошибок SQLSTATE.
  • Поддержка вызова функций и процедур.
  • Поддержка динамического построения SQL-запросов.
  • Возможность преобразование расширяемых типов данных на этапе передачи между клиентом и сервером (например, преобразования между массивами PostgreSQL и контейнерами STL).
  • Поддержка режима конвейерной передачи запросов (pipeline), позволяющего значительно ускорить выполнение большого числа мелких операций записи (INSERT/UPDATE/DELETE) за счёт отправки следующего запроса не дожидаясь результата предыдущего.
  • Поддержка Large Objects для потокового доступа к крупным наборам данных.
  • Поддержка операции COPY для копирования данных между файлом с СУБД.
  • Возможность отделения SQL-запросов от кода C++ на стороне клиента.
  • Предоставление простого и надёжного пула соединений, пригодного для использования в многопоточных приложениях.


  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Бета-версия клиентского C++ API Pgfe к PostgreSQL
  3. OpenNews: Обновление PostgreSQL с устранением уязвимостей. Выпуск балансировщика соединений Odyssey 1.2
  4. OpenNews: Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL
  5. OpenNews: Обновление PostgreSQL. Выпуск reshape, утилиты для миграции на новую схему без остановки работы
  6. OpenNews: Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД PostgreSQL
Автор новости: dmitigr
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/57039-pgfe
Ключевые слова: pgfe, postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:05, 18/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть сравнение с libpqxx?
     
     
  • 2.8, Аноним (8), 02:51, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    libpq на чистом C очень простая, приятная и удобная в работе вещь! Забудь про биндинги к плюсам (за исключением универсальных либ с возможностью поменять драйвер СУБД), там сложнее и хуже.

    P.S. Я серьезно, постгрес один из немногих случаев, когда сразу сделано нормально и удобно.

     
     
  • 3.17, Аноним (17), 12:18, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Забудь про биндинги к плюсам

    Без классов - не по феншую.

     
     
  • 4.26, Аноним (26), 21:20, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Без классов - не по феншую.

    Реализации классов типа DBconnection/dataset поверх чисто сишной libpq получаются очень компактными и простыми. И здесь во многом заслуга сишного API libpq.

    Умещался в 2 модуля .cpp/.h: самый большой - меньше 1000 строк, в сумме - около 2000 строк. Ради такой фигни выбирать отдельную либу как-то и не хочется... RAII/подходящий variant/логи,обработку ошибок,исключения и т.д. проще самому добавить по вкусу.

     
  • 4.30, adolfus (ok), 02:10, 23/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ООП плохо стыкуется с базами данных. Причем на всех уровнях -- от ISAM, что внизу, до SQL, что над ним. Паридигмы несовместимы. В С++ выручает только то, что это не ОО язык, а язык с некоторыми элементами ООП, которые можно просто отодвинуть в сторону. На бейсике удобнее с базами работать, нежели на любом из ОО языков.
     
  • 2.20, dmitigr (ok), 17:20, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, современней и является отечественным ПО ;-)
     

  • 1.5, Аноним (5), 23:38, 18/04/2022 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –9 +/
     
     
  • 2.6, Аноним (6), 01:13, 19/04/2022 Скрыто модератором
  • –7 +/
     
     
  • 3.7, Заноним (?), 02:50, 19/04/2022 Скрыто модератором
  • +1 +/
     
  • 3.9, aaaaa (?), 02:55, 19/04/2022 Скрыто модератором
  • +2 +/
     
  • 3.12, Аноним (12), 07:49, 19/04/2022 Скрыто модератором
  • +/
     
  • 2.13, Аноним (13), 07:51, 19/04/2022 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (5)

  • 1.10, Аноним (10), 03:14, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Когда-то писал свой драйвер Postges для C++. Подключение было неблокирующее по бинарному протоколу с динамической генерацией конвертации из бинарных данных Postgres в переменные C++ и обратно. С помощью шаблонов во время компиляции определялся тип переменной C++, а во время рантайма запрашивались типы полей в базе. Так становилось понятно, какие типы куда конвертировать. Далее генерировались функции преобразования из, например, PG:bigint в C++:int32 для ответов и обратно для запросов. Для этого изначально компилировался объектник с разными преобразованиями и из него в mmaped память копировались тела нужных функций в нужном порядке с релокациями (в результате для преобразования нужно было обратиться к одной большой функции конвертации через указатель - остальное линейный код, т.е. для select bigint, real, varchar в int, float, string генерировалась фукнция преобразования трех переменных из байтового массива, пришедшего от Postgres). Делается через mmap(), запись туда кода, mprotect(m, size, PROT_READ | PROT_EXEC) и вызов кода по указателю (в общем, все, как в Java/UPX).

    Забурился на том, что для генерации работы с std::string пришлось разбираться, что делать с исключениями (а там не просто скопировать сишную функцию с релокацией, там еще нужно обеспечить раскрутку стека, если, например, создание строки бросит исключение).

    P.S. Конвейерная передача запросов (pipeline) имеет жесткое и неприятное ограничение - в случае ошибки в одном запросе все последующие отменяются и это нужно отслеживать.

     
  • 1.11, aaaaa (?), 04:24, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    как в сравнении с yandex/ozo?
     
     
  • 2.21, dmitigr (ok), 17:27, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гораздо больше возможностей. В версии 2.1 будет добавлен API асинхронного ввода/вывода на базе обратных вызовов, что позволит использовать Pgfe в приложениях с циклом событий на базе разных его реализаций (в первую очередь, на базе libuv, но, вероятно, будет и поддержка ASIO, как в Ozo).
     
     
  • 3.22, aaaaa (?), 18:42, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дмитрий, приветствую! Спасибо за обратную связь!
    Поддержка asio была бы замечательным дополнением.
    Я в своем web frameworkе использую boost.asio + boost.beast и в качестве backendа для pgsql ковыряю ozo, но в ozo смущает медленное развитие и отсутствие коммитов уже год.
     
     
  • 4.23, dmitigr (ok), 19:44, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Постараюсь добавить поддержку ASIO. Issue по данной задаче -- https://github.com/dmitigr/pgfe/issues/14

    По любой проблеме можете смело открывать issue ;-)

     

  • 1.14, Аноним (-), 08:11, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Как ни крути, а библиотеки должны быть с сишным интерфейсом.
     
     
  • 2.15, Аноним (15), 10:25, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Прикол в том, что для конечного программиста максимально удобной является обертка в ООП, причем даже визуальное или полу-визуальное. Фиг знает, как это правильно объяснить. Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП. Оно естественное чисто потому, что так тупо будет меньше кода. А количество кода = трудозатраты программиста. Так зачем каждый раз изобретать велосипед? Именно поэтому мне нравится идея Delphi/Lazarus и очень жаль, что для C++ нет свободной альтернативы C++ Builder.
     
     
  • 3.16, Аноним (16), 10:32, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого есть Qt. Но есть нюанс :]
     
  • 3.19, Аноним (12), 13:57, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > максимально удобной является обертка в ООП

    Ты путаешь язык и парадигму. ООПить можно хоть на ассемблере.

     
  • 3.24, Аноним (-), 19:58, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Удобство это только одна сторона медали.
     
  • 3.25, Аноним (-), 19:59, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП

    Вам так часто нужно наследование?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру