feat: rename v1 to v2

Author: calvinbrewer

DEVELOPMENT.md

@@ -77,14 +77,14 @@ All files must have at least one declaration, and the default is to reference th
 
 ## Set up a local development environment
 
-> [!IMPORTANT]
-> **Before you follow this how-to** you need to have this software installed:
->  - [mise](https://mise.jdx.dev/) — see the [installing mise](#installing-mise) instructions
->  - [Docker](https://www.docker.com/) — see Docker's [documentation for installing](https://docs.docker.com/get-started/get-docker/)
+> [!IMPORTANT] > **Before you follow this how-to** you need to have this software installed:
+>
+> - [mise](https://mise.jdx.dev/) — see the [installing mise](#installing-mise) instructions
+> - [Docker](https://www.docker.com/) — see Docker's [documentation for installing](https://docs.docker.com/get-started/get-docker/)
 
 Local development quickstart:
 
-``` shell
+```shell
 # Clone the repo
 git clone https://github.com/cipherstash/encrypt-query-language
 cd encrypt-query-language
@@ -222,12 +222,11 @@ You can also [run the tests locally](#running-tests-locally) when doing local de
 
 ### Running tests locally
 
-> [!IMPORTANT]
-> **Before you run the tests locally** you need to [set up a local dev environment](#set-up-a-local-development-environment).
+> [!IMPORTANT] > **Before you run the tests locally** you need to [set up a local dev environment](#set-up-a-local-development-environment).
 
 To run tests locally with PostgreSQL 17:
 
-``` shell
+```shell
 # Start a postgres instance (defaults to PostgreSQL 17)
 mise run postgres:up --extra-args "--detach --wait"
 
@@ -292,67 +291,66 @@ mise run build
 
 This produces two SQL files in `releases/`:
 
- - An installer (`cipherstash-encrypt.sql`), and
- - An uninstaller (`cipherstash-encrypt-uninstall.sql`)
+- An installer (`cipherstash-encrypt.sql`), and
+- An uninstaller (`cipherstash-encrypt-uninstall.sql`)
 
 ## Structure
 
 ### Schema
 
-EQL is installed into the `eql_v1` PostgreSQL schema.
+EQL is installed into the `eql_v2` PostgreSQL schema.
 
 ### Types
 
 #### Encrypted column type
 
-`public.eql_v1_encrypted` is EQL's encrypted column type, defined as PostgreSQL composite type.
+`public.eql_v2_encrypted` is EQL's encrypted column type, defined as PostgreSQL composite type.
 
 This column type is used for storing the encrypted value and any associated indexes for searching.
 The associated indexes are described in the [index term types](#index-term-types) section.
 
-`public.eql_v1_encrypted` is in the public schema, because once it's used by a user in one of their tables, encrypted column types cannot be dropped without dropping data.
+`public.eql_v2_encrypted` is in the public schema, because once it's used by a user in one of their tables, encrypted column types cannot be dropped without dropping data.
 
 #### Encrypted index term types
 
 Each type of encrypted index (`unique`, `match`, `ore`) has an associated type, functions, and operators.
 
 These are transient runtime types, used internally by EQL functions and operators:
 
-- `eql_v1.blake3`
-- `eql_v1.unique_index`
-- `eql_v1.match`
-- `eql_v1.ore_cllw_u64_8`
-- `eql_v1.ore_cllw_var_8`
-- `eql_v1.ore_64_8_v1`
-- `eql_v1.ore_64_8_v1_term`
+- `eql_v2.blake3`
+- `eql_v2.unique_index`
+- `eql_v2.match`
+- `eql_v2.ore_cllw_u64_8`
+- `eql_v2.ore_cllw_var_8`
+- `eql_v2.ore_64_8_v2`
+- `eql_v2.ore_64_8_v2_term`
 
 The data in the column is converted into these types, when any operations are being performed on that encrypted data.
 
 ### Operators
 
 Searchable encryption functionality is driven by operators on two types:
 
-- EQL's `eql_v1_encrypted` column type
+- EQL's `eql_v2_encrypted` column type
 - PostgreSQL's `jsonb` column type
 
-For convenience, operators allow comparisons between `eql_v1_encrypted` and `jsonb` column types.
+For convenience, operators allow comparisons between `eql_v2_encrypted` and `jsonb` column types.
 
 Operators allow comparisons between:
 
-- `eql_v1_encrypted` and `eql_v1_encrypted`
-- `jsonb` and `eql_v1_encrypted`
-- `eql_v1_encrypted` and `jsonb`
+- `eql_v2_encrypted` and `eql_v2_encrypted`
+- `jsonb` and `eql_v2_encrypted`
+- `eql_v2_encrypted` and `jsonb`
 
-Operators defined on the `eql_v1_encrypted` dispatch to the underlying index terms based on the most efficient order of operations.
+Operators defined on the `eql_v2_encrypted` dispatch to the underlying index terms based on the most efficient order of operations.
 
 For example, it is possible to have both `unique` and `ore` indexes defined.
 For equality (`=`, `<>`) operations, a `unique` index term is a text comparison and should be preferred over an `ore` index term.
 
-The index term types and functions are internal implementation details and should not be exposed as operators on the `eql_v1_encrypted` type.
-For example, `eql_v1_encrypted` should not have an operator with the `ore_64_8_v1` type.
+The index term types and functions are internal implementation details and should not be exposed as operators on the `eql_v2_encrypted` type.
+For example, `eql_v2_encrypted` should not have an operator with the `ore_64_8_v2` type.
 Users should never need to think about or interact with EQL internals.
 
-
 #### Working without operators
 
 There are scenarios where users are unable to install EQL operators in your database.
@@ -363,12 +361,12 @@ EQL can still be used, but requires the use of functions instead of operators.
 For example, to perform an equality query:
 
 ```sql
-SELECT email FROM users WHERE eql_v1.eq(email, $1);
+SELECT email FROM users WHERE eql_v2.eq(email, $1);
 ```
 
 ### Configuration table
 
-EQL uses a table for tracking configuration state in the database, called `public.eql_v1_configuration`.
+EQL uses a table for tracking configuration state in the database, called `public.eql_v2_configuration`.
 
 This table should never be dropped, except by a user explicitly uninstalling EQL.
 
@@ -381,14 +379,14 @@ Experimenting with using a Composite type instead of a Domain type for the encry
 Composite types are a bit more capable. Domain types are more like an alias for the underlying type (in this case jsonb)
 The consequence of using a Composite type is that the data is stored in the column as a Tuple - effectively the data is wrapped in ()
 This means
-on insert/update the data needs to be cast to eql_v1_encrypted (proxy mapping will handle)
+on insert/update the data needs to be cast to eql_v2_encrypted (proxy mapping will handle)
 on read the data needs to be cast back to jsonb if a customer needs the raw json (for data lake transfer etc etc)
 Already built cast helpers so syntax is something like
     INSERT INTO encrypted (e) VALUES (
-        eql_v1.to_encrypted('{}')
+        eql_v2.to_encrypted('{}')
     );
 
     INSERT INTO encrypted (e) VALUES (
-        '{}'::jsonb::eql_v1_encrypted
+        '{}'::jsonb::eql_v2_encrypted
     );
 -->

README.md

@@ -77,23 +77,23 @@ Once the custom types and functions are installed in your PostgreSQL database, y
 
 ### Enable encrypted columns
 
-Define encrypted columns using the `eql_v1_encrypted` type, which extends the `jsonb` type with additional constraints to ensure data integrity.
+Define encrypted columns using the `eql_v2_encrypted` type, which extends the `jsonb` type with additional constraints to ensure data integrity.
 
 **Example:**
 
 ```sql
 CREATE TABLE users (
     id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
-    encrypted_email eql_v1_encrypted
+    encrypted_email eql_v2_encrypted
 );
 ```
 
 ### Configuring the column
 
-Initialize the column using the `eql_v1.add_column` function to enable encryption and decryption via CipherStash Proxy.
+Initialize the column using the `eql_v2.add_column` function to enable encryption and decryption via CipherStash Proxy.
 
 ```sql
-SELECT eql_v1.add_column('users', 'encrypted_email');
+SELECT eql_v2.add_column('users', 'encrypted_email');
 ```
 
 **Note:** This function allows you to encrypt and decrypt data but does not enable searchable encryption. See [Searching data with EQL](#searching-data-with-eql) for enabling searchable encryption.
@@ -103,8 +103,8 @@ SELECT eql_v1.add_column('users', 'encrypted_email');
 After modifying configurations, activate them by running:
 
 ```sql
-SELECT eql_v1.encrypt();
-SELECT eql_v1.activate();
+SELECT eql_v2.encrypt();
+SELECT eql_v2.activate();
 ```
 
 **Important:** These functions must be run after any modifications to the configuration.
@@ -114,7 +114,7 @@ SELECT eql_v1.activate();
 CipherStash Proxy refreshes the configuration every 60 seconds. To force an immediate refresh, run:
 
 ```sql
-SELECT eql_v1.reload_config();
+SELECT eql_v2.reload_config();
 ```
 
 > Note: This statement must be executed when connected to CipherStash Proxy.
@@ -191,10 +191,10 @@ In order to perform searchable operations on encrypted data, you must configure
 
 ### Adding an index
 
-Add an index to an encrypted column using the `eql_v1.add_index` function:
+Add an index to an encrypted column using the `eql_v2.add_index` function:
 
 ```sql
-SELECT eql_v1.add_index(
+SELECT eql_v2.add_index(
   'table_name',       -- Name of the table
   'column_name',      -- Name of the column
   'index_name',       -- Index kind ('unique', 'match', 'ore', 'ste_vec')
@@ -208,7 +208,7 @@ You can read more about the index configuration options [here](docs/reference/IN
 **Example (Unique index):**
 
 ```sql
-SELECT eql_v1.add_index(
+SELECT eql_v2.add_index(
   'users',
   'encrypted_email',
   'unique',
@@ -219,8 +219,8 @@ SELECT eql_v1.add_index(
 After adding an index, you have to activate the configuration:
 
 ```sql
-SELECT eql_v1.encrypt();
-SELECT eql_v1.activate();
+SELECT eql_v2.encrypt();
+SELECT eql_v2.activate();
 ```
 
 ## Searching data with EQL
@@ -231,12 +231,12 @@ In order to use the specialized functions, you must first configure the correspo
 
 ### Equality search
 
-Enable equality search on encrypted data using the `eql_v1.unique` function.
+Enable equality search on encrypted data using the `eql_v2.unique` function.
 
 **Index configuration example:**
 
 ```sql
-SELECT eql_v1.add_index(
+SELECT eql_v2.add_index(
   'users',
   'encrypted_email',
   'unique',
@@ -248,7 +248,7 @@ SELECT eql_v1.add_index(
 
 ```sql
 SELECT * FROM users
-WHERE eql_v1.unique(encrypted_email) = eql_v1.unique(
+WHERE eql_v2.unique(encrypted_email) = eql_v2.unique(
   '{"v":1,"k":"pt","p":"[email protected]","i":{"t":"users","c":"encrypted_email"},"q":"unique"}'
 );
 ```
@@ -261,12 +261,12 @@ SELECT * FROM users WHERE email = '[email protected]';
 
 ### Full-text search
 
-Enables basic full-text search on encrypted data using the `eql_v1.match` function.
+Enables basic full-text search on encrypted data using the `eql_v2.match` function.
 
 **Index configuration example:**
 
 ```sql
-SELECT eql_v1.add_index(
+SELECT eql_v2.add_index(
   'users',
   'encrypted_email',
   'match',
@@ -279,7 +279,7 @@ SELECT eql_v1.add_index(
 
 ```sql
 SELECT * FROM users
-WHERE eql_v1.match(encrypted_email) @> eql_v1.match(
+WHERE eql_v2.match(encrypted_email) @> eql_v2.match(
   '{"v":1,"k":"pt","p":"test","i":{"t":"users","c":"encrypted_email"},"q":"match"}'
 );
 ```
@@ -292,7 +292,7 @@ SELECT * FROM users WHERE email LIKE '%test%';
 
 ### Range queries
 
-Enable range queries on encrypted data using the `eql_v1.ore_64_8_v1`, `eql_v1.ore_cllw_u64_8`, or `eql_v1.ore_cllw_var_8` functions. Supports:
+Enable range queries on encrypted data using the `eql_v2.ore_64_8_v2`, `eql_v2.ore_cllw_u64_8`, or `eql_v2.ore_cllw_var_8` functions. Supports:
 
 - `ORDER BY`
 - `WHERE`
@@ -301,7 +301,7 @@ Enable range queries on encrypted data using the `eql_v1.ore_64_8_v1`, `eql_v1.o
 
 ```sql
 SELECT * FROM users
-WHERE eql_v1.ore_64_8_v1(encrypted_date) < eql_v1.ore_64_8_v1(
+WHERE eql_v2.ore_64_8_v2(encrypted_date) < eql_v2.ore_64_8_v2(
   '{"v":1,"k":"pt","p":"2023-10-05","i":{"t":"users","c":"encrypted_date"},"q":"ore"}'
 );
 ```
@@ -316,7 +316,7 @@ SELECT * FROM users WHERE date < '2023-10-05';
 
 ```sql
 SELECT id FROM users
-ORDER BY eql_v1.ore_64_8_v1(encrypted_field) DESC;
+ORDER BY eql_v2.ore_64_8_v2(encrypted_field) DESC;
 ```
 
 Equivalent plaintext query:
@@ -331,13 +331,13 @@ EQL supports array operations on encrypted data:
 
 ```sql
 -- Get array length
-SELECT eql_v1.jsonb_array_length(encrypted_array) FROM users;
+SELECT eql_v2.jsonb_array_length(encrypted_array) FROM users;
 
 -- Get array elements
-SELECT eql_v1.jsonb_array_elements(encrypted_array) FROM users;
+SELECT eql_v2.jsonb_array_elements(encrypted_array) FROM users;
 
 -- Get array element ciphertexts
-SELECT eql_v1.jsonb_array_elements_text(encrypted_array) FROM users;
+SELECT eql_v2.jsonb_array_elements_text(encrypted_array) FROM users;
 ```
 
 ### JSON Path Operations
@@ -373,7 +373,7 @@ No, CipherStash Proxy is required to handle the encryption and decryption operat
 
 ### How is data encrypted in the database?
 
-Data is encrypted using CipherStash's cryptographic schemes and stored in the `eql_v1_encrypted` column as a JSONB payload.
+Data is encrypted using CipherStash's cryptographic schemes and stored in the `eql_v2_encrypted` column as a JSONB payload.
 Encryption and decryption are handled by CipherStash Proxy.
 
 ## Helper packages and examples