Open dvarrazzo opened 2 years ago
Would these Python types be subclasses of Generic[T]/Dumper
or are we simply adding a dictionary mapping of Postgres to Python types?
I'm taking a look at these types now. Looking at cid
, AFAICS there are no other operators - cid can only be compared with cid.
piro=# select oprleft::regtype, oprname, oprright::regtype from pg_operator
where oprleft = 'cid'::regtype or oprright = 'cid'::regtype;
┌─────────┬─────────┬──────────┐
│ oprleft │ oprname │ oprright │
├─────────┼─────────┼──────────┤
│ cid │ = │ cid │
└─────────┴─────────┴──────────┘
(1 row)
this means that, if we dump an object to a cid (for instance querying select * from pg_class where cmin = %s
) then we cannot dump the type as a number: it must be either unknown or cid.
The model I had in mind was the same of oid, but oids have more casts and operators to support mixing with numbers.
If this is the case, if loading a cid returns a Python integer, then loading it back we would need a Cid
wrapper. The Oid doesn't normally need such wrapper.
Uhm... I'm questioning if this would be useful at all, or for every type, or in both directions...
hi @dvarrazzo can you give little more information about what is expected/desired and where do we have a reference implementation for this? Thanks
Several types found in pg_catalog are not mapped to Python types.
We should introduce a
psycopg.types.catalog
module implementing mappings:oid
:uint32
(already implemented inpsycopg.types.numeric
).cid
:uint32
int2vector
: similar tosmallint[]
, with space-separated text representation, 0-based array binary representation.oidvector
: similar toint[]
, see int2vectortid
: pair(block, offset)
(uint32
,uint16
)xid
:uint32
xid8
:uint64
pg_lsn
:uint64
This query gives an overview of where the types are used:
select a.atttypid::regtype, relname, attname from pg_attribute a join pg_class c on a.attrelid = c.oid join pg_namespace s on s.oid = c.relnamespace where nspname = 'pg_catalog' order by a.atttypid::regtype::text, relname, attname;