v2.1.0 - Change default to LEAKPROOF "disabled"

🚀 Version 2.1.0

⚙ Changes:

• Configurable LEAKPROOF Attribute: Shifted the default stance on the LEAKPROOF attribute from always enabled to optional. This adjustment allows users to evaluate their security requirements and operational context to decide whether to activate the LEAKPROOF setting. It moves towards accommodating various deployment scenarios, from dedicated servers to cloud-based environments, including Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS), where the need for superuser rights can vary/are limited.

---

📝 Migration Guide from nanoid() Version 2.0.0 to 2.1.0:

Transitioning to version 2.1.0 involves assessing your current nanoid() function usage against your specific operational and security needs. Follow these steps to ensure a smooth migration:

1. Review and Decide on the LEAKPROOF Setting: Assess whether the LEAKPROOF attribute is necessary for your specific use case. If your environment requires strict security measures, you can keep it. Otherwise, you can now easily adjust this setting for enhanced compatibility with your deployment environment.

2. Update the nanoid() function: To disable the LEAKPROOF attribute, modify the function definition by commenting out or removing the LEAKPROOF line. You can make use of the nanoid.sql file and execute it.

Note: Prioritize testing any configuration changes in a controlled environment before applying them to your production systems. Additionally, ensure up-to-date backups to safeguard against data loss or configuration issues during the transition process — otherwise, this can be quite a career-limiting move.

---

Full Changelog: 2.0.0...2.1.0

v2.0.0 - Optimized Performance & Extended Parameters

🚀 Version 2.0.0

💡 Enhancements:

• Added Comments: Introduced comprehensive comments to provide clarity about the function and its parameters.
• Parameter Addition: Introduced a new parameter additionalBytesFactor to the nanoid() function to provide flexibility in calculating the step size.
• Parameter Validations: Added validations for parameters size, alphabet, and additionalBytesFactor to ensure they meet the specified criteria.
• Optimized Function: Introduced an optimized version of the function named nanoid_optimized for enhanced performance and reduced memory overhead.

⚙ Changes:

• Updated Default Values: Revised the default values of alphabetLength, mask, and step in the nanoid() function.
• Dropped Old Version: Dropped the old version of the nanoid() function to replace it with the enhanced version.
• Updated Function Attributes: Added LEAKPROOF and PARALLEL SAFE attributes to both nanoid() and nanoid_optimized for better safety and parallel execution capabilities.

🐞 Fixes:

• Step Size Limitation: Ensured the step size does not exceed 1024 for optimal performance.

❗ Deprecated:

• Previous version of nanoid() function.

---

Migration Guide from nanoid() Version 1.0.0 to 2.0.0

Before migrating to the newer version of the nanoid() function, it's essential to identify any usages of the older version. This guide will assist you in this process.

1. Check for Occurrences of Old nanoid() Function

You can query the PostgreSQL system catalogue to check all occurrences of the potential old nanoid() function. Here's an SQL script to identify all the places where the function is used:

SELECT p.proname                 AS function_name,
       n.nspname                 AS schema_name,
       l.lanname                 AS language,
       pg_get_functiondef(p.oid) AS function_definition
FROM pg_proc p
         JOIN
     pg_namespace n ON p.pronamespace = n.oid
         JOIN
     pg_language l ON p.prolang = l.oid
WHERE p.proname = 'nanoid';

This script will return the names, schema, language, and definition of any functions named nanoid. Review these results to ensure they match the old version's signature and definition.

2. Drop Found Occurrences

After verifying and ensuring you've backed up any essential data, you can drop the older version of the nanoid() function. Here's the SQL script to do this:

DROP FUNCTION IF EXISTS nanoid(int, text);

Note: This drop command is based on the function signature from version 1.0.0. If there are variations in your environment, adjust the parameters in the DROP FUNCTION statement accordingly.

Final Notes:

• Backup: Always back up your database before migrating or making changes. This ensures you can recover any lost data or functions.

• Testing: It's recommended to perform these migration steps first in a staging or development environment to ensure everything works as expected.

• Review: After dropping the function, review all application areas or scripts that called the old function. If necessary, update them to call the newer version with the appropriate parameters.

Following this guide, you should smoothly transition from the old nanoid() function to the enhanced version 2.0.0.

v1.0.0 - initial release

Version 1.0.0 🎉

The initial release introduces the nanoid() function that generates a unique, compact, and URL-friendly identifier based on the provided size and alphabet. It defaults to a size of 21 and uses a standard set of characters ranging from alphanumeric characters to specific symbols. The function leverages PostgreSQL's pgcrypto extension and is written solely in the PL/pgSQL language.