Комментарии 4
Здесь прекрасно всё. И ключ в шестнадцать байт и хранение зашифрованных, а не хешированных паролей. RSA на какой либе кстати? На мой взгляд БД должна хранить информацию и обеспечивать ACID и прочие плюшки БД. А всё остальное должно выполняться прикладом. Нет, я конечно видел здесь и статью где из постгреса почтовые рассылки отправляли. Можно конечно, но каждому инструменту - своё место, имхо.
А всё остальное должно выполняться прикладом
Это на самом деле большой вопрос, что есть прикладной софт. В теории, вы можете написать расширение на любимом вам языке. Это будет одновременно и "часть БД", потому что расширение, и "прикладной софт", потому что вы сами его написали, и это не распространяется вместе с БД.
Нужно ли UUID формировать на стороне SQL клиента и в БД хранить блоб (как вы бы это делали в sqlite) или можно/нужно пользоваться встроенными типами?
А кастомные типы, которые хранят сеты?
А jsonb, который умеет в индексы по полям JSON?
И т.д.
Расширения, хранимки, типы, и пр. - это и есть "плюшки бд" и вызов хранимки, которая шифрует данные - тоже использование "плюшки бд", потому что при правильном использовании это будет быстрее и безопаснее, чем делать тоже самое иными путями.
Где эта грань, когда заканчиваются "плюшки бд" и начинается прикладной софт?
ну pgcrypto полезный модуль, и шифрование может пригодиться, просто пример с паролем не удачный. Может подойти sharedKey от otp.
Проще было документацию по pgcrypto процитировать.
Асимметричные и симметричные ключи в PostgreSQL