Mengevaluasi Extension

Delapan chapter di belakang kita memperlihatkan betapa murahnya memasang extension: satu baris CREATE EXTENSION dan kemampuan baru menyatu dengan SQL. Justru kemurahan itulah jebakannya — keputusan yang hanya butuh satu baris untuk diambil bisa menuntut berbulan-bulan untuk dibatalkan, karena objek extension menempel pada skema, pada data, bahkan pada siklus upgrade server. Ekosistem PostgreSQL nyata berisi ribuan extension dengan kualitas merata dari production-grade hingga proyek garasi yang ditinggalkan pemiliknya. Chapter penutup section ini merangkum cara menilai kandidat sebelum dipasang: daftar periksa due diligence, audit langsung lewat katalog PostgreSQL, bukti nyata siapa yang berhak memasang, dan keterikatan paling sering dilupakan — bahwa tiap extension adalah tiket yang harus terbayar setiap kali server naik major version.

Daftar Periksa Sebelum Memasang #

Evaluasi extension adalah evaluasi dependensi jangka panjang, bukan evaluasi demo lima menit. Sembilan pertanyaan berikut menutupi hampir seluruh risiko yang muncul di produksi:

Item audit	Yang dicari	Red flag
Asal maintainer	Contrib inti (dirilis bersama PostgreSQL) atau komunitas dengan rekam jejak	Repository tanpa komit berarti lebih dari setahun
Matriks kompatibilitas versi	Daftar major PostgreSQL yang didukung, tercantum jelas	Hanya mendukung major version yang sudah tua
Irama rilis	Rilis mengikuti mayor PostgreSQL dan perbaikan bug	Versi terakhir berumur bertahun-tahun
Kesehatan issue tracker	Laporan direspons maintainer, perbaikan masuk rilis	Ratusan issue terbuka tanpa satu pun tanggapan
Kualitas dokumentasi	Dokumen resmi terpelihara, punya contoh pemakaian	Hanya README seadanya
Status trusted	Pemilik database dapat memasang sendiri	Kebutuhan sepele dipaksa lewat superuser
Kebutuhan superuser dan preload	Tanpa hak istimewa khusus bila tidak perlu	Menuntut `shared_preload_libraries` dan restart
Jejak kinerja	Overhead terukur, minimal memori tetap	Alokasi shared memory besar yang menggerus kapasitas
Lisensi	Terbuka dan kompatibel (gaya PostgreSQL)	Lisensi eksklusif atau batasan komersial tersembunyi

Empat baris pertama menilai organisasi di balik extension; tiga berikutnya menilai biaya operasional; dua terakhir menilai hukum dan kinerja. Extension contrib inti — seluruh yang dibedah section ini kecuali PostGIS — otomatis lulus lima baris pertama karena dirilis dan diuji bersama PostgreSQL sendiri oleh tim yang sama. Extension komunitas harus melewati sembilan baris penuh.

Menilai dari Katalog: Audit SQL #

Dua dari sembilan item di atas bisa dijawab tanpa membuka browser — katalog PostgreSQL sudah menyimpan jawabannya. View pg_available_extension_versions mencatat flag control file untuk setiap versi yang terpasang di sistem operasi, dan file berikut mengauditnya untuk delapan extension yang telah kita kenal:

sql
audit-katalog.sql
-- Due diligence dimulai dari katalog yang bisa ditanya langsung.
-- Server kursus hanya memasang paket contrib sehingga katalognya berisi
-- 45 extension -- bukan seluruh ekosistem yang jauh lebih besar.
SELECT count(*) AS extension_tersedia
FROM pg_available_extensions;

-- Empat pertanyaan audit untuk versi default tiap kandidat extension:
-- versi berapa, menuntut superuser?, ditandai trusted?, dan butuh
-- extension lain lebih dulu?
SELECT e.name,
       e.default_version,
       v.superuser,
       v.trusted,
       v.requires AS butuh_extension_lain
FROM pg_available_extensions e
JOIN pg_available_extension_versions v
  ON v.name = e.name
 AND v.version = e.default_version
WHERE e.name IN ('pg_stat_statements', 'pgcrypto', 'pg_trgm', 'citext',
                 'uuid-ossp', 'postgres_fdw', 'dblink', 'earthdistance')
ORDER BY e.name;

Output yang Dihasilkan:

text
 extension_tersedia 
--------------------
                 45
(1 row)

        name        | default_version | superuser | trusted | butuh_extension_lain 
--------------------+-----------------+-----------+---------+----------------------
 citext             | 1.6             | t         | t       | 
 dblink             | 1.2             | t         | f       | 
 earthdistance      | 1.2             | t         | f       | {cube}
 pg_stat_statements | 1.11            | t         | f       | 
 pg_trgm            | 1.6             | t         | t       | 
 pgcrypto           | 1.3             | t         | t       | 
 postgres_fdw       | 1.1             | t         | f       | 
 uuid-ossp          | 1.1             | t         | t       | 
(8 rows)

Dua pembacaan penting keluar dari tabel itu. Pertama, angka 45 di pembuka: katalog hanya mencerminkan paket yang terpasang di sistem operasi — bukan cerminan ekosistem — sehingga server produksi Anda yang memasang paket lain akan menampilkan daftar yang berbeda. Kedua, baris earthdistance memperlihatkan kolom requires yang bekerja: {cube} berarti extension tersebut menolak dipasang sebelum cube — dependensi antar-extension yang ikut membebani inventaris Anda. Soal kolom superuser yang tampil t di semua baris padahal pgcrypto terbukti bisa dipasang pemilik database: kolom itu mencatat flag mentah control file, sedangkan kolom trusted yang mengubah siapa pemegang hak efektif — dokumentasi menandainya dengan frasa “but see trusted”. Pembuktian perilakunya kita lakukan di bagian berikutnya.

Siapa yang Berhak Memasang: Bukti Nyata #

Eksperimen berikut menjawab item checklist trusted dan superuser secara empiris. Sebuah role non-superuser dibuat sebagai pemilik database baru, lalu role itu mencoba memasang dua extension: pgcrypto yang ditandai trusted dan dblink yang tidak. Statement CREATE EXTENSION dibungkus blok DO dengan penanganan exception insufficient_privilege agar kegagalan tercatat sebagai data, bukan menghentikan file:

sql
uji-trusted.sql
-- Eksperimen nyata: siapa yang berhak memasang extension trusted?
-- Peran non-superuser dibuat sebagai PEMILIK database baru, lalu mencoba
-- memasang dua extension: pgcrypto (trusted) dan dblink (tidak trusted).
DROP DATABASE IF EXISTS db_evaluasi;
DROP ROLE IF EXISTS pemilik_evaluasi;

CREATE ROLE pemilik_evaluasi LOGIN;

CREATE DATABASE db_evaluasi OWNER pemilik_evaluasi;

-- Berpindah sebagai pemilik database yang bukan superuser.
\connect db_evaluasi pemilik_evaluasi

CREATE TEMP TABLE hasil_uji (extension text, hasil text);

-- pgcrypto ditandai trusted: pemilik database boleh memasangnya sendiri.
DO $$
BEGIN
    EXECUTE 'CREATE EXTENSION pgcrypto';
    INSERT INTO hasil_uji VALUES ('pgcrypto', 'diterima');
EXCEPTION WHEN insufficient_privilege THEN
    INSERT INTO hasil_uji VALUES ('pgcrypto', 'ditolak: ' || SQLERRM);
END
$$;

-- dblink tidak trusted: hanya superuser yang boleh memasangnya.
DO $$
BEGIN
    EXECUTE 'CREATE EXTENSION dblink';
    INSERT INTO hasil_uji VALUES ('dblink', 'diterima');
EXCEPTION WHEN insufficient_privilege THEN
    INSERT INTO hasil_uji VALUES ('dblink', 'ditolak: ' || SQLERRM);
END
$$;

SELECT extension, hasil
FROM hasil_uji
ORDER BY extension;

-- Pemilik boleh melepas apa yang dipasangnya sendiri.
DROP EXTENSION pgcrypto;

-- Kembali sebagai superuser untuk membersihkan objek uji.
\connect postgres postgres

DROP DATABASE db_evaluasi;
DROP ROLE pemilik_evaluasi;

Output yang Dihasilkan:

text
DROP DATABASE
DROP ROLE
CREATE ROLE
CREATE DATABASE
You are now connected to database "db_evaluasi" as user "pemilik_evaluasi".
CREATE TABLE
DO
DO
 extension |                          hasil                          
-----------+---------------------------------------------------------
 dblink    | ditolak: permission denied to create extension "dblink"
 pgcrypto  | diterima
(2 rows)

DROP EXTENSION
You are now connected to database "postgres" as user "postgres".
DROP DATABASE
DROP ROLE

Hasilnya tegas: pgcrypto diterima pemilik database, dblink ditolak dengan pesan permission denied to create extension "dblink". Konsekuensi desainnya simetris — extension yang membuka koneksi keluar, memuat pustaka berbahaya, atau menyentuh memori bersama (dblink, postgres_fdw, pg_stat_statements) dipagari superuser; extension murni-SQL yang aman (pgcrypto, citext, pg_trgm) cukup dipasang pemilik database tanpa melibatkan DBA. Di tim dengan pemisahan peran, kolom trusted menentukan apakah pengembang bisa self-service atau harus menempuh tiket ke tim operasional.

Keterikatan Upgrade Major Version #

Risiko paling mahal dari extension baru terasa justru bertahun kemudian, saat server harus naik major version. Pustaka setiap extension dikompilasi khusus untuk satu major — di server kursus, file postgres_fdw.so dan dblink.so tinggal di .../usr/lib/postgresql/17/lib/, dan angka 17 pada path itu menandakan binary-nya tidak akan dimuat oleh PostgreSQL 18. Saat pg_upgrade berjalan, setiap extension yang terpasang harus sudah tersedia dalam paket untuk versi mayor tujuan; satu saja yang tertinggal, seluruh upgrade terhenti atau memaksa extension itu dilepas lebih dulu beserta objek yang bergantung padanya.

Di sinilah ritme rilis maintainer menjadi menentukan. Extension contrib inti selalu siap di hari rilis major baru karena diuji bersama PostgreSQL. Extension komunitas datang kapan-kapan — berminggu-minggu, berbulan-bulan, atau tidak pernah — dan selama jeda itu upgrade cluster Anda menyandera satu extension. Tim yang matang karena itu menjalankan urutan ini: simpan inventaris extension, cek matriks kompatibilitasnya jauh sebelum jadwal upgrade, latih upgrade penuh di staging dengan seluruh extension terpasang, lalu berlangganan pengumuman rilis tiap maintainer.

Tur Ekosistem yang Sudah Anda Kenal #

Sebelum melihat nama-nama baru, mari rekap apa yang sudah Anda pegang. Delapan extension berikut dibedah tuntas di course ini:

Extension	Perannya dalam satu baris	Dibedah di
`pg_stat_statements`	Profil seluruh query server — profiler standar de facto	pg_stat_statements
`pgcrypto`	Hash, HMAC, dan enkripsi PGP di dalam SQL	pgcrypto
`uuid-ossp`	Generator UUID versi 1, 3, dan 5	UUID Functions
`postgres_fdw`	Foreign table ke PostgreSQL lain — federasi lintas database	postgres_fdw
`dblink`	Koneksi ad-hoc lintas database dari dalam SQL	dblink
PostGIS	Tipe spasial, fungsi `ST_*`, dan index GiST geografis	PostGIS
`pg_trgm`	Trigram untuk similaritas teks dan percepatan `LIKE`	GiST Index
`pg_partman`	Otomatisasi pembuatan dan rotasi partisi berkala	Partition Maintenance

Lima nama besar lain layak dikenali sejak sekarang meski tidak dibedah course ini. pg_repack menulis ulang tabel dan index tanpa ACCESS EXCLUSIVE lock yang panjang — alternatif VACUUM FULL di server sibuk. pgaudit menghasilkan log audit terstruktur untuk kebutuhan kepatuhan. TimescaleDB mengubah tabel time-series menjadi hypertable dengan kompresi dan retensi otomatis. Citus mem-shard tabel lintas cluster dan mendistribusikan query. Terakhir, pgvector menambahkan tipe vector dan pencarian similaritas — fondasi aplikasi AI di atas PostgreSQL. Kelimanya adalah extension komunitas besar dengan tim maintainer penuh, sehingga sembilan item checklist di atas akan terlewati — tetapi tetap terlewati, bukan dilewati.

Menghindari Penyebaran Extension #

Setiap extension yang terpasang adalah dependensi yang harus dilacak: versinya, kompatibilitasnya, dan jadwalnya mengikuti upgrade server. Lima extension terkurasi lebih mudah diurus daripada lima belas yang dipasang “sekadar mencoba” — penyakit yang umum disebut extension sprawl. Dua kebiasaan menjaganya tetap ramping. Pertama, lewat inventaris: daftar extension terpasang beserta alasannya, disimpan bersama konfigurasi infrastruktur agar tiap penambahan adalah keputusan sadar yang tercatat. Kedua, lewat schema khusus seperti ekstensi dari chapter Memasang dan Mengaktifkan Extension — objek extension yang berkelompok membuat audit pg_extension dan pembersihan CASCADE jauh lebih terkontrol.

Alur Keputusan Adopsi #

Seluruh bagian di atas terangkum menjadi satu alur keputusan yang bisa ditempel di dinding tim:

flowchart TD A[Kebutuhan nyata terdefinisi] --> B{Fitur inti PostgreSQL memadai?} B -- ya --> C[Selesaikan tanpa extension] B -- tidak --> D{Asal extension?} D -- contrib inti --> F D -- komunitas --> E{Maintainer aktif dan mendukung versi kita?} E -- tidak --> G[Cari alternatif atau tulis sendiri] E -- ya --> F{Menuntut superuser atau restart?} F -- tidak --> H[Pasang di schema khusus] F -- ya --> I[Koordinasikan dengan tim DBA] I --> H H --> J[Uji di staging dengan beban nyata] J --> K{Kinerja dan biaya pemeliharaan sesuai target?} K -- tidak --> G K -- ya --> L[Adopsi: catat di inventaris dependensi]

Tiga cabang di diagram itu layak digarisbawahi. Kotak Selesaikan tanpa extension adalah pintu keluar paling sering dilupakan: gen_random_uuid() bawaan menggantikan uuid-ossp untuk kebutuhan umum, dan partisi deklaratif native menggantikan separuh alasan orang memasang extension partisi. Cabang Maintainer aktif? adalah gerbang yang membedakan dependensi sehat dari beban mati. Dan terminal catat di inventaris dependensi mengingatkan bahwa adopsi tidak selesai saat CREATE EXTENSION sukses — ia baru selesai saat risiko upgrade-nya terkelola.

Kerangka evaluasi ini menutup section extension. PostgreSQL yang diperluas dengan extension terkurasi kini siap melayani aplikasi — dan aplikasi perlu cara bicara yang efisien dengannya. Section berikutnya, Integrasi Aplikasi , berpindah ke sisi kode: driver PHP, Go, Python, dan Node.js, connection pooling, serta pola query yang aman dari injeksi.

Referensi #

Berkas Sumber

Berkas pendukung halaman ini dapat diunduh dan dijalankan langsung sesuai penjelasan di atas.

sql
-- Due diligence dimulai dari katalog yang bisa ditanya langsung.
-- Server kursus hanya memasang paket contrib sehingga katalognya berisi
-- 45 extension -- bukan seluruh ekosistem yang jauh lebih besar.
SELECT count(*) AS extension_tersedia
FROM pg_available_extensions;

-- Empat pertanyaan audit untuk versi default tiap kandidat extension:
-- versi berapa, menuntut superuser?, ditandai trusted?, dan butuh
-- extension lain lebih dulu?
SELECT e.name,
       e.default_version,
       v.superuser,
       v.trusted,
       v.requires AS butuh_extension_lain
FROM pg_available_extensions e
JOIN pg_available_extension_versions v
  ON v.name = e.name
 AND v.version = e.default_version
WHERE e.name IN ('pg_stat_statements', 'pgcrypto', 'pg_trgm', 'citext',
                 'uuid-ossp', 'postgres_fdw', 'dblink', 'earthdistance')
ORDER BY e.name;

sql
-- Eksperimen nyata: siapa yang berhak memasang extension trusted?
-- Peran non-superuser dibuat sebagai PEMILIK database baru, lalu mencoba
-- memasang dua extension: pgcrypto (trusted) dan dblink (tidak trusted).
DROP DATABASE IF EXISTS db_evaluasi;
DROP ROLE IF EXISTS pemilik_evaluasi;

CREATE ROLE pemilik_evaluasi LOGIN;

CREATE DATABASE db_evaluasi OWNER pemilik_evaluasi;

-- Berpindah sebagai pemilik database yang bukan superuser.
\connect db_evaluasi pemilik_evaluasi

CREATE TEMP TABLE hasil_uji (extension text, hasil text);

-- pgcrypto ditandai trusted: pemilik database boleh memasangnya sendiri.
DO $$
BEGIN
    EXECUTE 'CREATE EXTENSION pgcrypto';
    INSERT INTO hasil_uji VALUES ('pgcrypto', 'diterima');
EXCEPTION WHEN insufficient_privilege THEN
    INSERT INTO hasil_uji VALUES ('pgcrypto', 'ditolak: ' || SQLERRM);
END
$$;

-- dblink tidak trusted: hanya superuser yang boleh memasangnya.
DO $$
BEGIN
    EXECUTE 'CREATE EXTENSION dblink';
    INSERT INTO hasil_uji VALUES ('dblink', 'diterima');
EXCEPTION WHEN insufficient_privilege THEN
    INSERT INTO hasil_uji VALUES ('dblink', 'ditolak: ' || SQLERRM);
END
$$;

SELECT extension, hasil
FROM hasil_uji
ORDER BY extension;

-- Pemilik boleh melepas apa yang dipasangnya sendiri.
DROP EXTENSION pgcrypto;

-- Kembali sebagai superuser untuk membersihkan objek uji.
\connect postgres postgres

DROP DATABASE db_evaluasi;
DROP ROLE pemilik_evaluasi;