Александр Павлюк, а как это достигается? Мне на ум приходит идея close вынести в отдельную функцию, чтобы сразу не закрывать соединение после того как функция отработает операцию, но, в этом случае, когда закрывать соединение не понятно. Дальше наверно надо делиться переменной dbpool с другими пакетами? Для этого наверно создать структуру, куда внести переменную *pgx.pool и использовать DI
calculator212 очень много ответов в инете по типу: неэскпортируемые поля делают программу безопаснее, ведь так невозможно изменять данные напрямую из других пакетов. Но наткнулся на один ответ, где сказано, что создание пустых геттеров и сеттеров для каждого поля ничем не отличается от того, чтобы просто делать их доступными напрямую. Если это правда, то это то, что мне нужно было понять. Теперь я могу начинать проект, делая все поля изначально неэкспортируемыми и дальше при необходимости делиться данными с другими пакетами буду думать делать доступ напрямую или писать геттеры/сеттеры с доп логикой.
Это похоже на то, что я хотел, но я имел ввиду такую хранимку:
CREATE PROCEDURE insert_data(a integer, b integer)
LANGUAGE SQL
AS $$
INSERT INTO tbl VALUES (a);
INSERT INTO tbl VALUES (b);
$$;
Там человек выше написал про библиотеку goose, которая инициализирует миграции и такие хранимки заодно, думаю это то, что я искал. Но про sql.Stmt я не знал, спасибо)