Комментарии 28
А как работать с типами, которые не перечислены в Table 37.1? Например, CIDR, UUID, JSONB, numeric и т.д.? Ещё есть домены, композитные типы.
Всегда инициализируйте новые объявленные структуры. Например, вызывайте memset() после palloc().
Для этого есть palloc0
Понятно, что интерфейс надо в extern «C» завернуть. Ну и в Makefile надо добавить
SHLIB_LINK = -lstdc++Про palloc/pfree — не понял. Зачем их обязательно использовать во внешних функциях?
И еще один важный момент — в Постгресе есть концепция background worker, что делает его невероятно расширяемым и гибким в сочетании с внешними функциями.
Про palloc/pfree — не понял. Зачем их обязательно использовать во внешних функциях?
Например, вы пишете агреггирующую функцию: у вас есть state transition function, вызываемая на каждую группируемую строку. Как вы сделаете free ранее выделенной памяти если запрос вдруг упирается в какую-то ошибку не имеющую к вашей функции отношения? И следующего sfunc банально не будет? Например, в temp_file_limit запрос упёрся и потому отменён.
Если вы выделяли память через palloc — то вся эта память будет автоматически очищена в этом случае вместе со всем контекстом запроса. Вот этот доклад с pgcon можно поглядеть чуть подробнее что такое memory context: www.pgcon.org/2019/schedule/events/1275.en.html
В initArrayResultArr создаётся контекст памяти.
Зато здесь есть хороший комментарий в array_agg_array_finalfn:
/*
* Make the result. We cannot release the ArrayBuildStateArr because
* sometimes aggregate final functions are re-executed. Rather, it is
* nodeAgg.c's responsibility to reset the aggcontext when it's safe to do
* so.
*/
Даже в final function освобождение памяти может быть неуместно, а лучше полагаться на удаление этого memory context в коде executor'а, выполняющего запрос.
По поводу смарт-пойнтеров не знаю, я на плюсах не пишу, да и
Чтобы смарт-поинтер справился, кто-то должен вызвать его деструктор. А его-то никто и не вызывает, потому что архитектура такая.
А что делать с возвращаемым значением? Кто вызовет его деструктор?
А чем не нравится palloc?
C++ позволяет переопределять new и писать свои аллокаторы для стандартных контейнеров. Вот пример того как можно возвращать объекты. Как указывает документация, во всю используется longjmp, а значит ваши любимые деструкторы могут не вызываться, что создаст утечку памяти.
Вот, например, код, который работает около 3 лет на сервере без утечек и без явных вызовов palloc — bitbucket.org/maxfo/pg_doc2vec
Конкретно внешние функции — bitbucket.org/maxfo/pg_doc2vec/src/master/extensions/client/pg_d2v_client.cpp
О том, что код не безопасный. Стоит ознакомиться с PG_TRY, PG_CATCH, PG_FINALLY, PG_END_TRY
Так почему же код не безопасный, объясните уже, пожалуйста.
Кто вызывает деструкторы, когда construct_array бросит ERRCODE_PROGRAM_LIMIT_EXCEEDED?
Обращаю внимание на документацию:
Вызывая серверные функции из кода C++, убедитесь, что в стеке вызова C++ содержатся только простые структуры данных. Это необходимо, потому что в случае ошибки сервера выполняется функция longjmp(), а она не отматывает стек вызовов C++ должным образом для объектов, отличных от простых структур.
Ну и ERRCODE_PROGRAM_LIMIT_EXCEEDED не «бросается». Где там в коде «бросание» через longjmp?
std::unique_ptr и std::vector сложные структуры у которых есть деструкторы.
Ну и ERRCODE_PROGRAM_LIMIT_EXCEEDED не «бросается».
Поэтому код является небезопасным, он написан без учета того, что в серверной функции будет ошибка.
Где там в коде «бросание» через longjmp?
errfinish дергает pg_re_throw, который и вызывает siglongjmp.
std::unique_ptr и std::vector сложные структуры у которых есть деструкторы.
так и почему их деструкторы не будет вызваны, давайте ссылку на конкретный код, который будет так чудесно разворачивать стек после неудачного вызова construct_array()
некоторые возможности PostgreSQL и вовсе нельзя сделать кроме как на С, например, в других языках не поддерживаются типы (особенно если возвращать значение из функции) ANYELEMENT, ANYARRAY и особенно важный VARIADIC.
Не, система типов работает безотносительно того, на каком языке написана функция. В частности, и на SQL, и в PL/pgSQL все это можно использовать.
Что, конечно, не умаляет достоинств Си.
PostgreSQL: Разработка расширений (функций) на языке С