Postgres 9.5 feature highlight: Import Foreign Schema
michael.otacoo.com
michael.otacoo.com
SELECT
'CREATE FOREIGN TABLE '
|| quote_ident('#{prefix}_' || c.relname)
|| '(' || array_to_string(array_agg(quote_ident(a.attname) || ' ' || t.typname), ', ') || ') '
|| ' SERVER #{prefix}_db OPTIONS'
|| ' (schema_name ''' || quote_ident(n.nspname) || ''', table_name ''' || quote_ident(c.relname) || ''');'
FROM
pg_class c,
pg_attribute a,
pg_type t,
pg_namespace n
WHERE
a.attnum > 0
AND a.attrelid = c.oid
AND a.atttypid = t.oid
AND n.oid = c.relnamespace
AND c.relkind in ('r', 'v')
AND n.nspname <> 'pg_catalog'
AND n.nspname <> 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
GROUP BY c.relname, n.nspname
ORDER BY c.relnameunderscore is standard for user-defined words (variables, table, databases). All-caps distinguishes built-ins to avoid confusion with user-defined. IMO with conventions, consistency is more important than the convention itself.
This may not be the right battle to be fighting. SQL reserved words have been written in all caps for a Very Long Time - it is a standard. From my personal experience, when I encounter legacy code where SQL keywords are lowercase I immediately think that the statements have been written by an inexperienced engineer (probably without any formal education).
The last time I encountered SQL statements with lowercase keywords, the individual included a table named user in their schema, causing all kinds of havoc, and reinforcing the stereotype.