In this post, I am sharing a best practice of creating any extension in Schema of PostgreSQL.

Using Extension, we can add additional functionality in PostgreSQL.
If we do not provide any schema specification, it will create under search_path schema which PUBLIC most of the time.

PostgreSQL: The Schema Search Path and change the default PUBLIC Schema

Now, why we should create an extension in schema?

For example, I created a ‘dblink’ extension without schema specification and I am using dblink functions without giving any schema name because it formed in search_path schema.

But, If I create a ‘dblink’ extension in dblink schema, we have to access dblink features by specifying the schema name of that extension. This is also good for code and other management as a backup of the schema.

Check the below example:

Create a user-defined schema:

CREATE SCHEMA dblink;

Create a dblink extension, under dblink schema:

CREATE EXTENSION dblink WITH SCHEMA dblink;

PostgreSQL [Video]: Cross Database Queries using DbLink Extension

If you don’t know what VM and FSM is, I would suggest to read below articles:

PostgreSQL: What is Visibility Map (VM)?

PostgreSQL: What is a Free Space Map (FSM)?

PostgreSQL 9.6 introduced a pg_visibility module to get the visibility map information of your table, and it is also giving page level information.
For removing fragmentation, and improve the query performance we should check the visibility map of our table.

For that, you need to create a pg_visibility module in PostgreSQL 9.6 and use it.
Previously, people are checking the suffix _vm files which associate with your relation.

Check the below demonstration on how to use pg_visibility:

Create a pg_visibility extension:

CREATE EXTENSION pg_visibility;

Create a sample table with 10000 dummy records:

CREATE TABLE tbl_checkvmap AS SELECT generate_series(1,10000) AS id;

Check the visibility map:

SELECT * FROM pg_visibility('tbl_checkvmap'::regclass);

This is going to be one of the most important article for the PostgreSQL community because I am going to share, what should be our best practice to store encrypted passwords into PostgreSQL Database Server.

I am sharing some of the important pgcrypto’s cryptographic functions for PostgreSQL password encryption.

Generally, people are using MD5 and SHA algorithm for password encryption, but both are easy to break and vulnerable, so we should not use this in our general practice.

The PostgreSQL provides pgcrypto module or extension with the set of cryptography functions.

First, We need to install the pgcrypto extension in PostgreSQL.

CREATE EXTENSION pgcrypto;

Below is a list of hashing algorithm along with its require bit size.

• MD5 = 128-bit hash value.
• SHA1 = 160-bit hash value.
• SHA224 = 224-bit hash value.
• SHA256 = 256-bit hash value.
• SHA384 = 384-bit hash value.
• SHA512 = 512-bit hash value.

Other Important Hashing Functions:

digest() :
It computes a binary hash of the given data. It supports all standard algorithms like: md5, sha1, sha224, sha256, sha384 and sha512.
We can use ENCODE() to convert a binary string into hexadecimal.

SELECT ENCODE(DIGEST('AnveshPassword','md5'),'hex');
SELECT ENCODE(DIGEST('AnveshPassword','sha1'),'hex');
SELECT ENCODE(DIGEST('AnveshPassword','sha224'),'hex');
SELECT ENCODE(DIGEST('AnveshPassword','sha256'),'hex');
SELECT ENCODE(DIGEST('AnveshPassword','sha384'),'hex');
SELECT ENCODE(DIGEST('AnveshPassword','sha512'),'hex');

hmac() :
It calculates hashed MAC for data with the key. This is similar to digest(), but more secure because it requires the key.We can use ENCODE() to convert a binary string into hexadecimal.

SELECT ENCODE(HMAC('AnveshPassword','mykey','md5'),'hex');
SELECT ENCODE(HMAC('AnveshPassword','mykey','sha1'),'hex');
SELECT ENCODE(HMAC('AnveshPassword','mykey','sha224'),'hex');
SELECT ENCODE(HMAC('AnveshPassword','mykey','sha256'),'hex');
SELECT ENCODE(HMAC('AnveshPassword','mykey','sha384'),'hex');
SELECT ENCODE(HMAC('AnveshPassword','mykey','sha512'),'hex');

crypt() and gen_salt() :
This is more secure than any other cryptographic functions.
This is specially designed for hashing passwords.
crypt() does the hashing and gen_salt() prepare algorithm parameters for it.

Generally, when we are using another algorithm like md5(), it generates the same string for same password text.

The most important point is, it generates a random string even for same password text.

Supported algorightms for crypt():
Reference taken from the PostgreSQL official document.

Below is a small demonstration of this:

Create a sample table:

CREATE TABLE tbl_TestPassword (MyPassword TEXT);

Insert a sample encrypted passwords:

INSERT INTO tbl_TestPassword VALUES (CRYPT('AnveshPassword', GEN_SALT('md5')));
INSERT INTO tbl_TestPassword VALUES (CRYPT('AnveshPassword', GEN_SALT('md5')));
INSERT INTO tbl_TestPassword VALUES (CRYPT('MyNewPassword', GEN_SALT('md5')));

Check the result and identify different string for even a same password:

SELECT *FROM tbl_TestPassword;

Check and authenticate given password:

SELECT *FROM tbl_TestPassword WHERE MyPassword = (CRYPT('AnveshPassword', MyPassword));

-- It returns two records.

SELECT *FROM tbl_TestPassword WHERE MyPassword = (CRYPT('MyNewPassword', MyPassword));

-- It returns one record.