Re: view on system tables upgrade II

Christoph Haller <ch(at)rodos(dot)fzk(dot)de> writes:
> Sorry, but I cannot figure out where in the join
> ...
> from pg_user u, pg_type t, pg_attribute a, pg_type n
> where u.usesysid = t.typowner
> and t.typrelid = a.attrelid and t.typtype = 'c' and not (t.typname ~* 'pg_')
> and n.typelem = a.atttypid
^^^^^^^^^^^^^^^^^^^^^^
> and substr(n.typname, 1, 1) = '_'
> and a.attnum > 0 ;
> I am assuming every datatype has an array type.

The row "pg_type n" is the array type corresponding to the datatype of
the "pg_attribute a" row. If there is no such array type, no join.
Since the select isn't actually doing anything with the "n" row, I'm
not sure why it's there at all.

Another thing that's slightly bizarre about this code is that it joins
attrelid to pg_type.typrelid, rather than pg_class.oid. I'd be inclined
to write the join as

from pg_attribute a,
pg_class c left join pg_user u on (u.usesysid = c.relowner)
where c.oid = a.attrelid and not (c.relname ~* 'pg_') and a.attnum > 0 ;

The outer join against pg_user guarantees that you won't miss tables
that have no owning user.

>> If you need timestamp arrays I'd suggest
>>
>> UPDATE pg_type SET typelem = 1114 WHERE oid = 1115;
>>
> Did the pg_attribute.atttypid resp. pg_type.typelem of timestamp change from
> 1184 to 1114?

1184 is timestamptz, 1114 is timestamp. But both _timestamptz and
_timestamp are pointing at 1184 as their typelem. I imagine this was
a cut-and-paste error...

regards, tom lane