`cidr` data type support

Problem

Support for the cidr PostgreSQL data type

Suggested solution

Introspecting a PostgreSQL database with a table that has a cidr column type does not list the column as unsupported. Perhaps it can devolve to a simple String field, but we would still get the type safety at the database level?

Alternatives

I suppose we could migrate our all of our cidr data types to a String and then move over to Prisma.

Additional context

Our team might be open to dedicating cycles to this change with some guidance if it is not too involved cc @dfellis

[dfellis]

There are also many built-in functions to manipulate cidr and inet types, particularly involving containment, determining the broadcast address of the relevant cidr range, etc postgresql.org/docs/current/functions-net.html

Would this mean the types support would also require function support like this in Prisma to be really useful and complete? How could these functions be surfaced in Prisma Client?

I wanted to sit and think on this, because while our immediate usage of it is primarily for the database’s input validation and normalization and the answer there is no, there are many “obvious” functions, particularly in use with the where clause that would need exposure in Prisma’s client to be available.

For example, answering the question “get all records with IP addresses in this CIDR range for Comcast users in California (so we can comply with CCPA regulations)”

That would be something like select * from access_logs where ip_address << '192.168.1.0/24'::cidr and the Prisma where would need to be something like:

const res = await prisma.accessLogs.findMany({
  where: {
    ipAddress: {
      containedBy: '192.168.1.0/24',
    },
  },
});

These presumably could also go into an insert, generating a result based on an operation from queried (or supplied) data, but on that front I actually don’t see any way in the prisma client to do an insert into ... select on existing data? So that might be moot.

[dfellis]

Hi @janpio

Is this about https://www.postgresql.org/docs/14/datatype-net-types.html#DATATYPE-CIDR?

Yes.

Are there any type specific functionalities in PostgreSQL that only work with this type (and that would fit in with this type work)?

Yes, there’s a whole host of database-side input validation first of all. There are also many built-in functions to manipulate cidr and inet types, particularly involving containment, determining the broadcast address of the relevant cidr range, etc https://www.postgresql.org/docs/current/functions-net.html

Are there equivalents for this data type on other databases?

MariaDB has the inet6 type that is a subset of this https://mariadb.com/kb/en/inet6/ but I don’t understand the relevancy here?

Is there any other way to represent this in Prisma Client besides a string?

There are several ways to represent the inet and cidr types.

1. The inet piece could be represented as an object with keys indicating IPv4/v6 type and the address itself could be represented as a BigInt if desired instead of the usual string representation. There are also multiple equivalent string representations that convert into a single canonical string representation, particularly with IPv6.
2. The cidr component could be represented as a bitmask field attached to such an object.
3. Or it could also be represented as an array of IP addresses that correspond to the base address + bitmask pair (invalid representations are possible with this form, though)
4. Or it could be an object with a start address and end address describing the range. (Invalid representations are also possible with this form)

I would like to note that the database we are trying to switch to Prisma for migrations already uses the cidr type, and the prisma documentation states full support of Postgres’ native types and automatic schema generation of them so we were surprised to run into this.