porting horde to Postgresql 12, dropped pg_attrdef

Horde (webmail and more) is not anymore compatible with postgresql 12
after pg_attrdef was dropped.

Since I'm a Horde user and I've always liked PostgreSQL I'm trying to
update these queries

1)

SELECT attr.attname,
CASE
WHEN split_part(def.adsrc, '''', 2) ~ '.' THEN
substr(split_part(def.adsrc, '''', 2),
strpos(split_part(def.adsrc, '''', 2), '.')+1)
ELSE split_part(def.adsrc, '''', 2)
END AS relname
FROM pg_class t
JOIN pg_attribute attr ON (t.oid = attrelid)
JOIN pg_attrdef def ON (adrelid = attrelid AND adnum = attnum)
JOIN pg_constraint cons ON (conrelid = adrelid AND adnum = conkey[1])
WHERE t.oid = '$table'::regclass
AND cons.contype = 'p'
AND def.adsrc ~* 'nextval';

This result eg in

attname | relname
---------+---------------------
id | horde_alarms_id_seq

2)

SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc,
a.attnotnull
FROM pg_attribute a
LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = ' . $this->quote($tableName) . '::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

This result eg in

attname | format_type | adsrc | attnotnull
id | integer | nextval('public.horde_alarms_id_seq'::regclass) | t

As for 1)

I think I can replicate the first query mixing up:

SELECT c.column_name, c.ordinal_position
FROM information_schema.key_column_usage AS c
LEFT JOIN information_schema.table_constraints AS t
ON t.constraint_name = c.constraint_name
WHERE
t.table_name = '<table_name>' AND t.constraint_type = 'PRIMARY KEY';

select pg_get_serial_sequence('<table_name>', '<column_name>')

But it would be nice to avoid something postgres specific to retrieve
the sequence name. Is there any alternative to pg_get_serial_sequence()?

The 2) query is used to fill a PHP object that seems to be used to
"recreate" the query to create the table.
I can get most of what I need from information_schema.columns but I was
wondering if there is a way to come up with actual "type definition" as
format_type() or pg_typeof().

Furthermore querying the information_schema.columns return
nextval('horde_alarms_id_seq'::regclass)

in spite of

nextval('public.horde_alarms_id_seq'::regclass)

and I wonder if it is going to make a difference and if there is a way
to totally mimic the result of the original query.

Thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net