The custom uuid implementation of asyncpg causes errors in my api

• asyncpg version: asyncpg==0.20.0
• PostgreSQL version: PostgreSQL 11.5 on x86_64-pc-linux-musl, compiled by gcc (Alpine 8.3.0) 8.3.0, 64-bit
• Do you use a PostgreSQL SaaS? If so, which? Can you reproduce the issue with a local PostgreSQL install?: no
• Python version: 3.8.0
• Platform: linux
• Do you use pgbouncer?: no
• Did you install asyncpg with pip?: yes
• If you built asyncpg locally, which version of Cython did you use?:
• Can the issue be reproduced under both asyncio and uvloop?: yes

I am using asyncpg to build a simple api using the library fastapi, the asyncpg implementation of uuid causes an error when I read a uuid from the database.

The uuid implementation of asynpg is not properly picked up by fastapi because they use type(obj) instead of instance(obj, uuid.UUID). Basically there is a defined list of types with their jsonification methods and asyncpg.pgproto.pgproto.UUID is not in that list. This piece of code demonstrates the issue:

import uuid
from asyncpg.pgproto import pgproto


def demonstrate_uuid_issue():
    asyncpg_uuid = pgproto.UUID("a10ff360-3b1e-4984-a26f-d3ab460bdb51")
    regular_uuid = uuid.UUID("a10ff360-3b1e-4984-a26f-d3ab460bdb51")

    print(regular_uuid == asyncpg_uuid)  # True
    print(isinstance(asyncpg_uuid, type(regular_uuid)))  # True
    print(type(asyncpg_uuid) == type(regular_uuid))  # False

The pgproto.UUID implementation does a pretty good job hiding it’s true colors but unfortunately it is still of a different type than the regular uuid.UUID. This basically throws an error in my api and forces me to use the regular uuid type like so:

await connection.set_type_codec('uuid',
                                encoder=str,
                                decoder=uuid.UUID,
                                schema='pg_catalog')

Someone already suggested to push your new uuid implementation upstream: https://github.com/MagicStack/py-pgproto/blob/484e3520d8cb0514b7596a8f9eaa80f3f7b79d0c/uuid.pyx#L324-L328 I think that would be an ideal solution to the problem. Are there any other steps I can take to resolve this issue on the asyncpg side of things?