Архив метки: PostgreSQL

 Резервное копирование и восстановление баз данных PostgreSQL

Создание резервной копии базы PostgreSQL




Идея, стоящая за методом дампа, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере, пересоздадут базу данных в том же самом состоянии, в котором она была на момент создания дампа. PostgreSQL предоставляет для этой цели программную утилиту pg_dump. Базовый форма команды выглядит так:




pg_dump имя_БД > файл_дампа




то-есть, pg_dump записывает результаты своей работы на стандартный вывод. Далее будет рассмотрено как из этого можно извлечь пользу.




pg_dump является для PostgreSQL обычным клиентским приложением. Процедура резервного копирования может выполняться с любого удалённого компьютера, который имеет доступ к нужной базе данных. Эта утилита должна иметь доступ на чтение всех таблиц базы данных, резервную копию которых вы хотите сделать, так что на практике её почти всегда нужно запускать с правами суперпользователя СУБД.




Чтобы указать, к какому серверу должен подключаться pg_dump, необходимо использовать опцию командной строки -h сервер и -p порт. По умолчанию, в качестве сервера выбирается localhost или тот сервер, что указан в переменной окружения PGHOST. Похожим образом, по умолчанию используется порт, указанный в переменной окружения PGPORT или, если переменная не заданна, то порт, указанный по умолчанию при компиляции.




Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных, под пользователем, имя которого совпадает с именем текущего пользователя в операционной системе. Чтобы изменить пользователя необходимо использовать опцию -U, либо установить нужное значение переменной окружения PGUSER.




Важное преимущество pg_dump над другими методами резервного копирования состоит в том, что базы данных, сохраненные при помощи pg_dump, могут быть залиты в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы (простое копирование файлов баз данных) являются жёстко зависимыми от версии сервера.




Также, только pg_dump является методом, который будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.




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




Если  схема базы данных полагается на OID (например, как внешние ключи), вы должны сказать pg_dump, чтобы в дамп были также включены OID. Чтобы сделать это, используйте опцию командной строки -o.




Команда pg_dump может сохранять резервную копию базы в двух форматах: в формате текстовых файлов, содержащих набор команд SQL и специальный формат дампа. Если PostgreSQL была скомпилирована в системе с установленной библиотекой zlib, то специальный формат дампа будет сжимать данные, которые выдаются в файл вывода. Это приведёт к созданию файла дампа, который по размеру будет похож на дамп, сжатый gzip, но такой формат будет иметь преимущество, потому что позволяет выборочное восстановление таблиц. Следующая команда делает дамп базы данных, используя специальный формат дампа:




pg_dump -Fc имя_БД > имя_файла




В принципе можно сжать и текстовый формат резервной копии используя стандартные инструменты Linux — ипользовать программу сжатия, например gzip:




pg_dump имя_БД | gzip > имя_файла.gz




распаковывая впоследствии сжатый дамп командой:




gunzip -c имя_файла.gz | psql имя_БД




или:




cat имя_файла.gz | gunzip | psql имя_БД




При больших базах данных и нежелании использовать сжатие можно использовать команду split. Команда split позволяет разбивать текстовые файлы на файлы меньшего размера, которые не попадают под ограничения на максимальный размер файла в файловой системе. Например, чтобы нарезать дамп на кусочки по 1 мегабайту:




pg_dump имя_БД | split -b 1m - имя_файла




Загружая впоследствии полученные файлы командой:




cat имя_файла* | psql имя_БД




Восстановление резервных копий баз PostgreSQL




Текстовые файлы резервных копий баз данных PostgreSQL, содержащие команды sql, предназначаются для последующего чтения программой psql, то-есть выполнения сгенерированной последовательности скриптов. Общий вид команды для восстановления дампа:




psql имя_БД < файл_дампа




где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой, так что ее необходимо предварительно создать из шаблона базы template0 перед запуском psql, например, с помощью команды:




createdb -T template0 имя_БД




psql поддерживает опции для указания сервера, к которому осуществляется подключение и имени пользователя, похожие на pg_dump.




Перед восстановлением SQL дампа, все пользователи, которые владеют объектами или имеют права на объекты в базе данных, выгруженной в дамп, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с оригинальными владельцами и/или правами.




По умолчанию, если произойдёт ошибка SQL, программа psql продолжит своё выполнение. Можно запустить psql с установленной переменной ON_ERROR_STOP, чтобы  заставить psql в случае возникновения ошибки SQL завершить работу с кодом 3:




psql --set ON_ERROR_STOP=on имя_БД < файл_дампа




В любом случае база данных будет только частично восстановлена. В качестве альтернативы можно задать, что-бы весь дамп должен быть восстановлен в одной транзации, так что восстановление или будет полностью выполненно или полностью не выполнено. Данный режим может быть задан, с помощью опций командной строки -1 или —single-transaction для psql.




Возможность pg_dump и psql писать и читать из конвееров, делают возможным создание дампа базы данных напрямую с одного сервера на другой, например:




pg_dump -h сервер1 имя_БД | psql -h сервер2 имя_БД




Дампы, которые делает pg_dump являются относительными template0. Это означает, что любые языки, процедуры и т.д. добавленные через template1, также попадут в дамп при выполнении pg_dump. В итоге, при восстановлении, если вы использовали специально изменённый template1, вы должны создать пустую базу данных из template0, как показано в примере выше.




После восстановления резервной копии, очень рекомендуется запустить ANALYZE на каждую базу данных для того, чтобы оптимизатор запросов получил нужную статистику.




Специальный формат дампа не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:




pg_restore -d имя_БД имя_файла




Для очень больших баз данных, вам может понадобиться сочетать split с одним из двух других методов.




Резервное копирование всего кластера баз данных PostgreSQL




pg_dump делает дамп только одной базы данных и не включает в дамп информацию о ролях или табличных пространствах (потому что эти данные относятся скорее к уровню кластера, чем к самой базе данных). Для создания резервной копии всего содержимого кластера баз данных, существует программа pg_dumpall. pg_dumpall делает резервную копию каждой базы данных кластера, а также служебные данные уровня кластера, такие как роли и определения табличных пространств. Базовая форма использования этой команды:




pg_dumpall > файл_дампа




Результирующий дамп может быть восстановлен с помощью psql:




psql -f файл_дампа postgres




При восстановлении дампа, сделанного pg_dumpall, всегда необходимо, выполнять восстановление с правами суперпользователя баз данных, потому что они требуются для восстановления ролей и информации о табличных пространствах.




Источник: https://www.oslogic.ru/knowledge/718/rezervnoe-kopirovanie-i-vosstanovlenie-baz-dannyh-postgresql/



2022-04-15T16:44:17
Software

PostgreSQL. Как создать базу данных в Windows 10?

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

Мы хотим сказать, что нам нужен механизм для проверки, существует ли база данных на нашем сервере PostgreSQL или нет. Более того, бывают ситуации, когда мы хотим, чтобы база данных создавалась после выполнения запроса, если она еще не существует на нашем сервере базы данных. В этом случае в игру вступает нотация «Создать базу данных, если не существует». Это руководство призвано познакомить вас с использованием этой нотации с кратким обсуждением того, поддерживает ли PostgreSQL эту нотацию или нет. После этого мы поделимся с вами альтернативой этой нотации, поддерживаемой PostgreSQL.

 

Можем ли мы использовать нотацию «Создать базу данных, если не существует» в PostgreSQL в Windows 10?

Обозначение «Создать базу данных, если не существует» поддерживается некоторыми языками программирования. С помощью этой нотации вы можете проверить, существует ли указанная база данных на вашем сервере баз данных или нет, и если она не существует, то эта нотация просто создаст эту базу данных на вашем сервере. Однако поговорим конкретно о PostgreSQL. PostgreSQL не поддерживает эту нотацию, или, другими словами, вы можете сказать, что мы не можем использовать эту нотацию непосредственно в PostgreSQL в Windows 10.

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

 

Если нет, то какое обходное решение мы можем использовать для достижения той же цели?

Поскольку нотация «Создать базу данных, если не существует» не может использоваться в среде PostgreSQL, поэтому мы решили поделиться с вами обходным путем, с помощью которого вы можете достичь той же функциональности. Для этого обходного пути вам нужно будет выполнить несколько иной вариант этой нотации в форме запроса PostgreSQL в Windows 10. Чтобы понять этот вариант, вам нужно будет выполнить шаги, описанные ниже:

Примечание
Не забудьте войти на свой сервер PostgreSQL, прежде чем выполнять эти шаги.

 

Шаг №1: просмотр существующих баз данных PostgreSQL в Windows 10:

Все мы знаем, что хотим создать конкретную базу данных в PostgreSQL только в том случае, если она уже существует на нашем сервере. База данных, которую мы хотим создать в данном конкретном случае, называется «myNewDB». Поэтому сначала мы попытаемся узнать имена всех наших существующих баз данных PostgreSQL, чтобы узнать, существует ли такая база данных на нашем сервере или нет. Чтобы отобразить имена всех существующих баз данных PostgreSQL, вам необходимо выполнить следующий запрос PostgreSQL в консоли psql:

# SELECT datname FROM pg_database;

 

Этот запрос извлечет атрибут «datname» из pg_database нашего сервера PostgreSQL. Этот атрибут содержит имена всех существующих баз данных на сервере PostgreSQL. Оператор SELECT в PostgreSQL просто отображает извлеченные имена баз данных на консоли, как показано ниже:

postgres=# SELECT datname FROM pg_database;

datname

postgres sampledb template1 template0 abc abcdb defdb mydb (8 rows)

postgres=#

Из вывода, показанного на изображении выше, видно, что на нашем сервере PostgreSQL нет базы данных с именем «myNewDB»; поэтому мы можем попытаться создать базу данных с этим именем на нашем сервере в Windows 10.

 

Шаг №2: Создание базы данных PostgreSQL, если она не существует в Windows 10:

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

# SELECT ‘CREATE DATABASE myNewDB’ WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = ‘myNewDB’)gexec

 

С помощью этого запроса мы создадим базу данных с именем «myNewDB», которой еще не было на нашем сервере PostgreSQL в нашей системе Windows 10. За оператором SELECT в этом запросе следует оператор CREATE DATABASE. После этого мы упомянули имя нашей новой базы данных, которую нужно создать. Вы можете называть его как хотите. Затем мы написали оператор «WHERE NOT EXISTS», который проверяет, существует ли указанная база данных на сервере PostgreSQL или нет. За всеми этими операторами следует подзапрос, в котором есть еще один оператор «SELECT FROM», который проверяет pg_database нашего сервера PostgreSQL, чтобы подтвердить отсутствие базы данных, которую вы пытаетесь создать.

Наконец, есть параметр «gexec», завершающий этот запрос. Этот параметр чрезвычайно важен в этом запросе. Этот параметр отправляет текущий буфер запроса на сервер PostgreSQL, где каждый компонент или атрибут вывода этого запроса обрабатывается как запрос SQL, а не как запрос PostgreSQL. Фактически, это основная причина работы нотации «Создать базу данных, если не существует» в PostgreSQL. В противном случае, даже если вы случайно пропустите этот параметр, вы не сможете реализовать эту функцию в PostgreSQL.

postgres=# SELECT 'CREATE DATABASE myNewDB' WHERE NOT EXISTS (SELECT FROM pg database WHERE datname = 'myNewDB')gexec

 

Если вы правильно выполните весь синтаксис этого запроса, то база данных PostgreSQL с указанным именем будет успешно создана на сервере PostgreSQL, что вы можете подтвердить из выходного ответа, показанного на изображении ниже:

postgres=# SELECT 'CREATE DATABASE myNewDB' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'myNewDB')gexec

CREATE DATABASE postgres=#

 

Шаг № 3: Проверка, была ли создана новая база данных PostgreSQL в Windows 10 или нет:

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

# SELECT datname  FROM pg_database;

 

На данный момент на нашем сервере PostgreSQL существует девять баз данных, и фактически самая последняя из них — это та, которую мы только что попытались создать, как показано ниже:

postgres=# SELECT datname FROM pg_database;

datname

postgres sampledb template1 template0 abc abcdb defdb mydb mynewdb (9 rows)

postgres=#

 

Заключение:

В этой статье говорилось о нотации «Создать базу данных, если не существует» и ее использовании. Затем мы обсудили, поддерживается ли эта нотация в PostgreSQL или нет. Узнав, что мы не можем использовать эту нотацию непосредственно в PostgreSQL, мы поделились с вами методом достижения той же функциональности, оставаясь в среде PostgreSQL.



2021-10-03T09:37:32
OS Windows

Настройка репликации PostgreSQL в контейнерах Docker

Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.




Подготовка компьютера




На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен Docker. Также мы сразу рассмотрим развертывание нужной нам инфраструктуры в docker-compose. Для установки необходимой одноименной платформы смотрим инструкцию Установка Docker на Linux.




После мы можем переходить к поднятию контейнеров.




Запуск контейнеров с СУБД




Как говорилось выше, мы будем поднимать наши контейнеры с помощью docker-compose.




Создадим каталог, в котором будем работать:




mkdir -p /opt/docker/postgresql




Переходим в него:




cd /opt/docker/postgresql




Создаем файл для docker-compose:




vi docker-compose.yml




---



services:



  postgresql_01:

    image: postgres

    container_name: postgresql_01

    restart: always

    volumes:

      - /data/postgresql_01:/var/lib/postgresql/data

    environment:

      POSTGRES_PASSWORD: postgres024



  postgresql_02:

    image: postgres

    container_name: postgresql_02

    restart: always

    volumes:

      - /data/postgresql_02/:/var/lib/postgresql/data

    environment:

      POSTGRES_PASSWORD: postgres024




* рассмотрим некоторый опции подробнее:







Запускаем наши контейнеры:




docker-compose up -d




Мы должны увидеть:




Creating postgresql_02 ... done

Creating postgresql_01 ... done




А если вывести список контейнеров:




docker ps




… мы должны увидеть наши два.




Теперь можно переходить к настройке репликации.




Настройка репликации




Условимся, что первичный сервер или master будет в контейнере с названием postgresql_01. Вторичный — postgresql_02. Мы будем настраивать потоковую (streaming) асинхронную репликацию.




Настройка на мастере




Подключаемся к контейнеру docker:




docker exec -it postgresql_01 bash




Заходим под пользователем postgres:




su - postgres




Создаем пользователя, под которым будем подключаться со стороны вторичного сервера:




createuser --replication -P repluser




* в данном примере будет создаваться учетная запись repluser с правами репликации.




Система потребует ввода пароля. Придумываем его и набираем дважды.




Выходим из-под пользователя postgres:




exit




Выходим из контейнера:




exit




Открываем конфигурационный файл postgresql.conf:




vi /data/postgresql_01/postgresql.conf




Приводим к следующием виду некоторые параметры:




wal_level = replica

max_wal_senders = 2

max_replication_slots = 2

hot_standby = on

hot_standby_feedback = on




* где







Посмотрим подсеть, которая используется для контейнеров с postgresql:




docker network inspect postgresql_default | grep Subnet




В моем случае, ответ был:




"Subnet": "172.19.0.0/16",




Теперь открываем файл:




vi /data/postgresql_01/pg_hba.conf




И добавляем строку после остальных «host    replication»:




host    replication     all             172.19.0.0/16           md5




* в данном примере мы разрешили подключение пользователю replication из подсети 172.19.0.0/16 с проверкой подлинности по паролю.




Перезапустим докер контейнер:




docker restart postgresql_01




Настройка на слейве




Выполним настройку вторичного сервера. Для начала, удалим содержимое рабочего каталога вторичной базы:




rm -r /data/postgresql_02/*




* в данном примере мы удалим все содержимое каталога /data/postgresql_02.




Мы должны быть уверены, что в базе нет ничего важного. Только после этого стоить удалять данные.




Заходим внутрь контейнера postgresql_02:




docker exec -it postgresql_02 bash




Выполняем команду:




su - postgres -c "pg_basebackup --host=postgresql_01 --username=repluser --pgdata=/var/lib/postgresql/data --wal-method=stream --write-recovery-conf"




* где postgresql_01 — наш мастер; /var/lib/postgresql/data — путь до каталога с данными слейва.




Система должна запросить пароль для пользователя repluser — вводим его. Начнется процесс репликации, продолжительность которого зависит от объема данных.




Проверка




Смотрим статус работы мастера:




docker exec -it postgresql_01 su - postgres -c "psql -c 'select * from pg_stat_replication;'"




Смотрим статус работы слейва:




docker exec -it postgresql_02 su - postgres -c "psql -c 'select * from pg_stat_wal_receiver;'"




Источник: https://www.dmosk.ru/miniinstruktions.php?mini=postgresql-replication-docker



2021-09-25T00:05:23

Защита PostgreSQL с помощью Fail2ban

В сегодняшней статье я расскажу как можно защитить PostgreSQL от атак перебора паролем или как его ещё называют – от Брутфорса (Brute Force).

После установки и настройки PostgreSQL Вы скорее всего задумывались о том, каким способом защитить вашу базу данных.

Один из способов это установка fail2ban, который на Ubuntu доступен в официальном репозитории. Но из коробки он работает только для SSH.

Давайте же разберемся, как включить его дня защиты postgresql. Читать →

Python: Django & PostgreSQL

Привет всем. Сегодня расскажу как подключать бд PostgreSQL(далее как постгрес) к фреймворку Джанго.

Итак, для начала установите pgAdmin. Качал я ее отсюда http://www.postgresql.org/download/ и как всегда самую последнюю версию. Процесс установки — я особо не заморачивался, кликал «далее». Теперь у меня на винде 8.1 есть такой менеджер — аналог phpmyadmin, как pgAdmin.

После этого нужно настроить общение с базой данных, для этого нужно некий драйвер, найти его можно по ссылке http://www.lfd.uci.edu/~gohlke/pythonlibs/ и найдите браузерным поиском такие два названия psycopg2-2.6.1-cp35-none-win32.whl  psycopg2-2.6.1-cp35-none-win_amd64.whl и нажмите на тот который подходит вашей системе и закиньте в папку site-packages которая находится у вас в папке проекта мой пример пути (D:djangopropyblogLibsite-packages) также можно ее закинуть в папку с таким же названием но уже в директории где установлен сам Python. Ну а теперь начнем связывать.

Для начала создайте базу данных в pgAdmin…

Далее найдите следующие строки в файле settings.py и замените их соответствующими данными вашей БД

'ENGINE': 'django.db.backends.postgresql_psycopg2', — должна быть одинакова у всех для использования постгреса.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2', 
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': '123',
        'HOST': '',
        'PORT': '',
    }
}

Следующим шагом будет создание суперпользователя админки, но после того как вы подключите адаптер для БД. Делается это так
В консоли когда у вас запущено виртуальное окружение Джанго(смотрите прошлую статью http://pythlife.blogspot.com/2016/03/django-project-folder-create.html) — запись в консоли выглядит примерно так (pyblog) D:djangoproblogblog> , перейдите в папку где хранится ваша преднастройка проекта(из прошло записи, правильно называть виртуальное окружение) у меня это путь D:djangopropyblogLibsite-packages -> пишите команду pip install psycopg2-2.6.1-cp35-none-win32.whl

В итоге строка в консоли выглядит так:
(pyblog) D:djangopropyblogLibsite-packages> pip install sycopg2-2.6.1-cp35-none-win32.whl

Установка будет удачной если вам не высыпить никаких ерроров. 
Переходим в директорию нашего проекта где лежит файл manage.py и выполняем такую команду
python manage.py migrate auth
python manage.py migrate
python manage.py createsuperuser

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



























Запускаем сервер в консоли в директории с файлом manage.py .
python manage.py runserver
Переходим по ссылке http://127.0.0.1:8000/admin/ вводим данные и попадаем в админку.

На этом я заканчиваю… в итоге мы подключили БД, создали суперюзера и попали в админку, дальше будет интересней — обещаю!

Автор: Няшный Человек
Дата публикации: 2016-03-27T20:33:00.000+03:00

aiopg и SQLAlchemy

Выпустил новую версию aiopg 0.2 — библиотеки для работы с PostgreSQL из asyncio.

aiopg использует асинхронные вызовы и в этом похож на txpostgres и momoko — библиотеки для работы с PostgreSQL под twisted и tornado соответственно.

В новой версии aiopg появилась опциональная поддержка SQLAlchemy Core Expressions.

Проще один раз показать.

Создаем описание структуры базы данных:

import sqlalchemy as sa

metadata = sa.MetaData()

users = sa.Table('users', metadata,
                 sa.Column('id', sa.Integer, primary_key=True),
                 sa.Column('name', sa.String(255)),
                 sa.Column('birthday', sa.DateTime))

emails = sa.Table('emails', metadata,
                  sa.Column('id', sa.Integer, primary_key=True),
                  sa.Column('user_id', None, sa.ForeignKey('users.id')),
                  sa.Column('email', sa.String(255), nullable=False),
                  sa.Column('private', sa.Boolean, nullable=False))

Как видите — две таблицы, связанные отношением один-ко-многим. Для тех, кто не знаком — алхимия позволяет описать любую модель данных, которая только может прийти в голову. Индексы, constraints, пользовательские типы данных такие как array и hstore — тоже.

Теперь нужно сделать engine:

from aiopg.sa import create_engine

engine = yield from create_engine(user='aiopg',
                                  database='aiopg',
                                  host='127.0.0.1',
                                  password='passwd')

engine содержит внутри connection pool.

Для работы с БД нужно получить connection и что-нибудь выполнить:

with (yield from engine) as conn:
    uid = yield from conn.scalar(
        users.insert().values(name='Andrew', birthday=datetime(1978, 12, 9)))

Обратите внимание: диалект знает о INSERT ... RETURNING и позвращает primary key для вставляемой записи.

Работа с транзакциями:

with (yield from engine) as conn:
    tr = yield from conn.begin()

    # Do something

    yield from tr.commit()

Получение данных:

with (yield from engine) as conn:
    res = yield from conn.execute(users.select())
    for row in res:
        print(res)

Сложный запрос:

with (yield from engine) as conn:
    join = sa.join(emails, users, users.c.id == emails.c.user_id)
    query = (sa.select([users.c.name])
             .select_from(join)
             .where(emails.c.private == 0)
             .group_by(users.c.name)
             .having(sa.func.count(emails.c.private) > 0))

    print("Users with public emails:")
    ret = yield from conn.execute(query)
    for row in ret:
        print(row.name)

Вызов SQL функций:

with (yield from engine) as conn:
    query = (sa.select([sa.func.avg(sa.func.age(users.c.birthday))])
             .select_from(users))
    ave = (yield from conn.scalar(query))
    print("Average age of population is", ave,
          "or ~", int(ave.days / 365), "years")

sa.func.avg и sa.func.age выполняются на стороне SQL сервера.

Полный код примера здесь, документация здесь.

Автор: Andrew Svetlov