Prepared statements with bind variables only work when the SQL string is static and only the variables change - but ORMS are used to construct full SQL statements with custom select / while / join clauses etc.
This way the query sent to the server looks like this:
SELECT * FROM whatever WHERE email = :1 AND user_name = :2;
This way the database server knows what is user provided data and what is part of the SQL, and no special quoting is required since the database server handles that internally. It's much safer in that SQL injection becomes impossible at that point.
Depending on how complex your query is it can get to be a bit of work but it's doable.
as compared to: https://github.com/rails/rails/compare/v4.1.2...v4.1.3 and https://github.com/rails/rails/compare/v4.0.6...v4.0.7
https://gist.github.com/thbar/7dc97d3f5f6a52e4fa00
(obviously not to be used in a CI environment).
Also, if you want to make sure you get push notification for security updates, check out this:
http://thibautbarrere.com/how-to-get-push-notifications-for-...
(I get only critical stuff as pushes, and get notified even in the rare case that the rails security email goes to spam as it happened once previously).
https://github.com/blog/1440-github-enterprise-email-inciden...
PostgreSQL itself isn't responsible or affected, contrary to what the "Vulnerabilities Affecting PostgreSQL" phrasing suggests at a glance.
select
cn.nspname as schema,
relname as table,
attname as column,
tn.nspname as type_schema,
typname as type_name
from pg_attribute a
inner join pg_class c on a.attrelid = c.oid
inner join pg_namespace cn on c.relnamespace = cn.oid
inner join pg_type t on a.atttypid = t.oid
inner join pg_namespace tn on t.typnamespace = tn.oid
where (t.typtype = 'r' or t.typname = 'bit' or t.typname = 'varbit');