Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide data type mapping for catalog types #320

Open
dvarrazzo opened this issue Jun 17, 2022 · 3 comments
Open

Provide data type mapping for catalog types #320

dvarrazzo opened this issue Jun 17, 2022 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@dvarrazzo
Copy link
Member

dvarrazzo commented Jun 17, 2022

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 in psycopg.types.numeric).
  • cid: uint32
  • int2vector: similar to smallint[], with space-separated text representation, 0-based array binary representation.
  • oidvector: similar to int[], see int2vector
  • tid: 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;

@dvarrazzo dvarrazzo added enhancement New feature or request good first issue Good for newcomers labels Jun 17, 2022
@bbibenyo-spiria
Copy link

bbibenyo-spiria commented Jun 20, 2022

Would these Python types be subclasses of Generic[T]/Dumper or are we simply adding a dictionary mapping of Postgres to Python types?

@dvarrazzo
Copy link
Member Author

dvarrazzo commented Jun 20, 2022

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...

@itsankitkp
Copy link

hi @dvarrazzo can you give little more information about what is expected/desired and where do we have a reference implementation for this?
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants