Prompt file imported from lightspeedwp/utils (.github/prompts/awesome-copilot/postgresql-code-review.prompt.md). Fill in {{selection}} before use. Copyright stays with the author.

PostgreSQL Code Review Assistant

Name: postgresql-code-review
Author: lightspeedwp

Expert PostgreSQL code review for {{selection}} (or entire project if no selection). Focus on PostgreSQL-specific best practices, anti-patterns, and quality standards that are unique to PostgreSQL.

🎯 PostgreSQL-Specific Review Areas

JSONB Best Practices

-- ❌ BAD: Inefficient JSONB usage
SELECT * FROM orders WHERE data->>'status' = 'shipped';  -- No index support

-- ✅ GOOD: Indexable JSONB queries
CREATE INDEX idx_orders_status ON orders USING gin((data->'status'));
SELECT * FROM orders WHERE data @> '{"status": "shipped"}';

-- ❌ BAD: Deep nesting without consideration
UPDATE orders SET data = data || '{"shipping":{"tracking":{"number":"123"}}}';

-- ✅ GOOD: Structured JSONB with validation
ALTER TABLE orders ADD CONSTRAINT valid_status
CHECK (data->>'status' IN ('pending', 'shipped', 'delivered'));

Array Operations Review

-- ❌ BAD: Inefficient array operations
SELECT * FROM products WHERE 'electronics' = ANY(categories);  -- No index

-- ✅ GOOD: GIN indexed array queries
CREATE INDEX idx_products_categories ON products USING gin(categories);
SELECT * FROM products WHERE categories @> ARRAY['electronics'];

-- ❌ BAD: Array concatenation in loops
-- This would be inefficient in a function/procedure

-- ✅ GOOD: Bulk array operations
UPDATE products SET categories = categories || ARRAY['new_category']
WHERE id IN (SELECT id FROM products WHERE condition);

PostgreSQL Schema Design Review

-- ❌ BAD: Not using PostgreSQL features
CREATE TABLE users (
    id INTEGER,
    email VARCHAR(255),
    created_at TIMESTAMP
);

-- ✅ GOOD: PostgreSQL-optimized schema
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email CITEXT UNIQUE NOT NULL,  -- Case-insensitive email
    created_at TIMESTAMPTZ DEFAULT NOW(),
    metadata JSONB DEFAULT '{}',
    CONSTRAINT valid_email CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')
);

-- Add JSONB GIN index for metadata queries
CREATE INDEX idx_users_metadata ON users USING gin(metadata);

Custom Types and Domains

-- ❌ BAD: Using generic types for specific data
CREATE TABLE transactions (
    amount DECIMAL(10,2),
    currency VARCHAR(3),
    status VARCHAR(20)
);

-- ✅ GOOD: PostgreSQL custom types
CREATE TYPE currency_code AS ENUM ('USD', 'EUR', 'GBP', 'JPY');
CREATE TYPE transaction_status AS ENUM ('pending', 'completed', 'failed', 'cancelled');
CREATE DOMAIN positive_amount AS DECIMAL(10,2) CHECK (VALUE > 0);

CREATE TABLE transactions (
    amount positive_amount NOT NULL,
    currency currency_code NOT NULL,
    status transaction_status DEFAULT 'pending'
);

🔍 PostgreSQL-Specific Anti-Patterns

Performance Anti-Patterns

Avoiding PostgreSQL-specific indexes: Not using GIN/GiST for appropriate data types
Misusing JSONB: Treating JSONB like a simple string field
Ignoring array operators: Using inefficient array operations
Poor partition key selection: Not leveraging PostgreSQL partitioning effectively

Schema Design Issues

Not using ENUM types: Using VARCHAR for limited value sets
Ignoring constraints: Missing CHECK constraints for data validation
Wrong data types: Using VARCHAR instead of TEXT or CITEXT
Missing JSONB structure: Unstructured JSONB without validation

Function and Trigger Issues

-- ❌ BAD: Inefficient trigger function
CREATE OR REPLACE FUNCTION update_modified_time()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = NOW();  -- Should use TIMESTAMPTZ
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- ✅ GOOD: Optimized trigger function
CREATE OR REPLACE FUNCTION update_modified_time()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = CURRENT_TIMESTAMP;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Set trigger to fire only when needed
CREATE TRIGGER update_modified_time_trigger
    BEFORE UPDATE ON table_name
    FOR EACH ROW
    WHEN (OLD.* IS DISTINCT FROM NEW.*)
    EXECUTE FUNCTION update_modified_time();

📊 PostgreSQL Extension Usage Review

Extension Best Practices

-- ✅ Check if extension exists before creating
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";

-- ✅ Use extensions appropriately
-- UUID generation
SELECT uuid_generate_v4();

-- Password hashing
SELECT crypt('password', gen_salt('bf'));

-- Fuzzy text matching
SELECT word_similarity('postgres', 'postgre');

🛡️ PostgreSQL Security Review

Row Level Security (RLS)

-- ✅ GOOD: Implementing RLS
ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;

CREATE POLICY user_data_policy ON sensitive_data
    FOR ALL TO application_role
    USING (user_id = current_setting('app.current_user_id')::INTEGER);

Privilege Management

-- ❌ BAD: Overly broad permissions
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;

-- ✅ GOOD: Granular permissions
GRANT SELECT, INSERT, UPDATE ON specific_table TO app_user;
GRANT USAGE ON SEQUENCE specific_table_id_seq TO app_user;

🎯 PostgreSQL Code Quality Checklist

Schema Design

Using appropriate PostgreSQL data types (CITEXT, JSONB, arrays)
Leveraging ENUM types for constrained values
Implementing proper CHECK constraints
Using TIMESTAMPTZ instead of TIMESTAMP
Defining custom domains for reusable constraints

Performance Considerations

Appropriate index types (GIN for JSONB/arrays, GiST for ranges)
JSONB queries using containment operators (@>, ?)
Array operations using PostgreSQL-specific operators
Proper use of window functions and CTEs
Efficient use of PostgreSQL-specific functions

PostgreSQL Features Utilization

Using extensions where appropriate
Implementing stored procedures in PL/pgSQL when beneficial
Leveraging PostgreSQL's advanced SQL features
Using PostgreSQL-specific optimization techniques
Implementing proper error handling in functions

Security and Compliance

Row Level Security (RLS) implementation where needed
Proper role and privilege management
Using PostgreSQL's built-in encryption functions
Implementing audit trails with PostgreSQL features

📝 PostgreSQL-Specific Review Guidelines

Data Type Optimization: Ensure PostgreSQL-specific types are used appropriately
Index Strategy: Review index types and ensure PostgreSQL-specific indexes are utilized
JSONB Structure: Validate JSONB schema design and query patterns
Function Quality: Review PL/pgSQL functions for efficiency and best practices
Extension Usage: Verify appropriate use of PostgreSQL extensions
Performance Features: Check utilization of PostgreSQL's advanced features
Security Implementation: Review PostgreSQL-specific security features

Focus on PostgreSQL's unique capabilities and ensure the code leverages what makes PostgreSQL special rather than treating it as a generic SQL database.

# PostgreSQL Code Review Assistant Expert PostgreSQL code review for {{selection}} (or entire project if no selection). Focus on PostgreSQL-specific best practices, anti-patterns, and quality standards that are unique to PostgreSQL. ## 🎯 PostgreSQL-Specific Review Areas ### JSONB Best Practices ```sql -- ❌ BAD: Inefficient JSONB usage SELECT * FROM orders WHERE data->>'status' = 'shipped'; -- No index support -- ✅ GOOD: Indexable JSONB queries CREATE INDEX idx_orders_status ON orders USING gin((data->'status')); SELECT * FROM orders WHERE data @> '{"status": "shipped"}'; -- ❌ BAD: Deep nesting without consideration UPDATE orders SET data = data || '{"shipping":{"tracking":{"number":"123"}}}'; -- ✅ GOOD: Structured JSONB with validation ALTER TABLE orders ADD CONSTRAINT valid_status CHECK (data->>'status' IN ('pending', 'shipped', 'delivered')); ``` ### Array Operations Review ```sql -- ❌ BAD: Inefficient array operations SELECT * FROM products WHERE 'electronics' = ANY(categories); -- No index -- ✅ GOOD: GIN indexed array queries CREATE INDEX idx_products_categories ON products USING gin(categories); SELECT * FROM products WHERE categories @> ARRAY['electronics']; -- ❌ BAD: Array concatenation in loops -- This would be inefficient in a function/procedure -- ✅ GOOD: Bulk array operations UPDATE products SET categories = categories || ARRAY['new_category'] WHERE id IN (SELECT id FROM products WHERE condition); ``` ### PostgreSQL Schema Design Review ```sql -- ❌ BAD: Not using PostgreSQL features CREATE TABLE users ( id INTEGER, email VARCHAR(255), created_at TIMESTAMP ); -- ✅ GOOD: PostgreSQL-optimized schema CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, email CITEXT UNIQUE NOT NULL, -- Case-insensitive email created_at TIMESTAMPTZ DEFAULT NOW(), metadata JSONB DEFAULT '{}', CONSTRAINT valid_email CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$') ); -- Add JSONB GIN index for metadata queries CREATE INDEX idx_users_metadata ON users USING gin(metadata); ``` ### Custom Types and Domains ```sql -- ❌ BAD: Using generic types for specific data CREATE TABLE transactions ( amount DECIMAL(10,2), currency VARCHAR(3), status VARCHAR(20) ); -- ✅ GOOD: PostgreSQL custom types CREATE TYPE currency_code AS ENUM ('USD', 'EUR', 'GBP', 'JPY'); CREATE TYPE transaction_status AS ENUM ('pending', 'completed', 'failed', 'cancelled'); CREATE DOMAIN positive_amount AS DECIMAL(10,2) CHECK (VALUE > 0); CREATE TABLE transactions ( amount positive_amount NOT NULL, currency currency_code NOT NULL, status transaction_status DEFAULT 'pending' ); ``` ## 🔍 PostgreSQL-Specific Anti-Patterns ### Performance Anti-Patterns - **Avoiding PostgreSQL-specific indexes**: Not using GIN/GiST for appropriate data types - **Misusing JSONB**: Treating JSONB like a simple string field - **Ignoring array operators**: Using inefficient array operations - **Poor partition key selection**: Not leveraging PostgreSQL partitioning effectively ### Schema Design Issues - **Not using ENUM types**: Using VARCHAR for limited value sets - **Ignoring constraints**: Missing CHECK constraints for data validation - **Wrong data types**: Using VARCHAR instead of TEXT or CITEXT - **Missing JSONB structure**: Unstructured JSONB without validation ### Function and Trigger Issues ```sql -- ❌ BAD: Inefficient trigger function CREATE OR REPLACE FUNCTION update_modified_time() RETURNS TRIGGER AS $$ BEGIN NEW.updated_at = NOW(); -- Should use TIMESTAMPTZ RETURN NEW; END; $$ LANGUAGE plpgsql; -- ✅ GOOD: Optimized trigger function CREATE OR REPLACE FUNCTION update_modified_time() RETURNS TRIGGER AS $$ BEGIN NEW.updated_at = CURRENT_TIMESTAMP; RETURN NEW; END; $$ LANGUAGE plpgsql; -- Set trigger to fire only when needed CREATE TRIGGER update_modified_time_trigger BEFORE UPDATE ON table_name FOR EACH ROW WHEN (OLD.* IS DISTINCT FROM NEW.*) EXECUTE FUNCTION update_modified_time(); ``` ## 📊 PostgreSQL Extension Usage Review ### Extension Best Practices ```sql -- ✅ Check if extension exists before creating CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "pgcrypto"; CREATE EXTENSION IF NOT EXISTS "pg_trgm"; -- ✅ Use extensions appropriately -- UUID generation SELECT uuid_generate_v4(); -- Password hashing SELECT crypt('password', gen_salt('bf')); -- Fuzzy text matching SELECT word_similarity('postgres', 'postgre'); ``` ## 🛡️ PostgreSQL Security Review ### Row Level Security (RLS) ```sql -- ✅ GOOD: Implementing RLS ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY; CREATE POLICY user_data_policy ON sensitive_data FOR ALL TO application_role USING (user_id = current_setting('app.current_user_id')::INTEGER); ``` ### Privilege Management ```sql -- ❌ BAD: Overly broad permissions GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user; -- ✅ GOOD: Granular permissions GRANT SELECT, INSERT, UPDATE ON specific_table TO app_user; GRANT USAGE ON SEQUENCE specific_table_id_seq TO app_user; ``` ## 🎯 PostgreSQL Code Quality Checklist ### Schema Design - [ ] Using appropriate PostgreSQL data types (CITEXT, JSONB, arrays) - [ ] Leveraging ENUM types for constrained values - [ ] Implementing proper CHECK constraints - [ ] Using TIMESTAMPTZ instead of TIMESTAMP - [ ] Defining custom domains for reusable constraints ### Performance Considerations - [ ] Appropriate index types (GIN for JSONB/arrays, GiST for ranges) - [ ] JSONB queries using containment operators (@>, ?) - [ ] Array operations using PostgreSQL-specific operators - [ ] Proper use of window functions and CTEs - [ ] Efficient use of PostgreSQL-specific functions ### PostgreSQL Features Utilization - [ ] Using extensions where appropriate - [ ] Implementing stored procedures in PL/pgSQL when beneficial - [ ] Leveraging PostgreSQL's advanced SQL features - [ ] Using PostgreSQL-specific optimization techniques - [ ] Implementing proper error handling in functions ### Security and Compliance - [ ] Row Level Security (RLS) implementation where needed - [ ] Proper role and privilege management - [ ] Using PostgreSQL's built-in encryption functions - [ ] Implementing audit trails with PostgreSQL features ## 📝 PostgreSQL-Specific Review Guidelines 1. **Data Type Optimization**: Ensure PostgreSQL-specific types are used appropriately 2. **Index Strategy**: Review index types and ensure PostgreSQL-specific indexes are utilized 3. **JSONB Structure**: Validate JSONB schema design and query patterns 4. **Function Quality**: Review PL/pgSQL functions for efficiency and best practices 5. **Extension Usage**: Verify appropriate use of PostgreSQL extensions 6. **Performance Features**: Check utilization of PostgreSQL's advanced features 7. **Security Implementation**: Review PostgreSQL-specific security features Focus on PostgreSQL's unique capabilities and ensure the code leverages what makes PostgreSQL special rather than treating it as a generic SQL database.

{ "prompt": "# PostgreSQL Code Review Assistant\n\nExpert PostgreSQL code review for {{selection}} (or entire project if no selection). Focus on PostgreSQL-specific best practices, anti-patterns, and quality standards that are unique to PostgreSQL.\n\n## 🎯 PostgreSQL-Specific Review Areas\n\n### JSONB Best Practices\n\n```sql\n-- ❌ BAD: Inefficient JSONB usage\nSELECT * FROM orders WHERE data->>'status' = 'shipped'; -- No index support\n\n-- ✅ GOOD: Indexable JSONB queries\nCREATE INDEX idx_orders_status ON orders USING gin((data->'status'));\nSELECT * FROM orders WHERE data @> '{\"status\": \"shipped\"}';\n\n-- ❌ BAD: Deep nesting without consideration\nUPDATE orders SET data = data || '{\"shipping\":{\"tracking\":{\"number\":\"123\"}}}';\n\n-- ✅ GOOD: Structured JSONB with validation\nALTER TABLE orders ADD CONSTRAINT valid_status\nCHECK (data->>'status' IN ('pending', 'shipped', 'delivered'));\n```\n\n### Array Operations Review\n\n```sql\n-- ❌ BAD: Inefficient array operations\nSELECT * FROM products WHERE 'electronics' = ANY(categories); -- No index\n\n-- ✅ GOOD: GIN indexed array queries\nCREATE INDEX idx_products_categories ON products USING gin(categories);\nSELECT * FROM products WHERE categories @> ARRAY['electronics'];\n\n-- ❌ BAD: Array concatenation in loops\n-- This would be inefficient in a function/procedure\n\n-- ✅ GOOD: Bulk array operations\nUPDATE products SET categories = categories || ARRAY['new_category']\nWHERE id IN (SELECT id FROM products WHERE condition);\n```\n\n### PostgreSQL Schema Design Review\n\n```sql\n-- ❌ BAD: Not using PostgreSQL features\nCREATE TABLE users (\n id INTEGER,\n email VARCHAR(255),\n created_at TIMESTAMP\n);\n\n-- ✅ GOOD: PostgreSQL-optimized schema\nCREATE TABLE users (\n id BIGSERIAL PRIMARY KEY,\n email CITEXT UNIQUE NOT NULL, -- Case-insensitive email\n created_at TIMESTAMPTZ DEFAULT NOW(),\n metadata JSONB DEFAULT '{}',\n CONSTRAINT valid_email CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$')\n);\n\n-- Add JSONB GIN index for metadata queries\nCREATE INDEX idx_users_metadata ON users USING gin(metadata);\n```\n\n### Custom Types and Domains\n\n```sql\n-- ❌ BAD: Using generic types for specific data\nCREATE TABLE transactions (\n amount DECIMAL(10,2),\n currency VARCHAR(3),\n status VARCHAR(20)\n);\n\n-- ✅ GOOD: PostgreSQL custom types\nCREATE TYPE currency_code AS ENUM ('USD', 'EUR', 'GBP', 'JPY');\nCREATE TYPE transaction_status AS ENUM ('pending', 'completed', 'failed', 'cancelled');\nCREATE DOMAIN positive_amount AS DECIMAL(10,2) CHECK (VALUE > 0);\n\nCREATE TABLE transactions (\n amount positive_amount NOT NULL,\n currency currency_code NOT NULL,\n status transaction_status DEFAULT 'pending'\n);\n```\n\n## 🔍 PostgreSQL-Specific Anti-Patterns\n\n### Performance Anti-Patterns\n\n- **Avoiding PostgreSQL-specific indexes**: Not using GIN/GiST for appropriate data types\n- **Misusing JSONB**: Treating JSONB like a simple string field\n- **Ignoring array operators**: Using inefficient array operations\n- **Poor partition key selection**: Not leveraging PostgreSQL partitioning effectively\n\n### Schema Design Issues\n\n- **Not using ENUM types**: Using VARCHAR for limited value sets\n- **Ignoring constraints**: Missing CHECK constraints for data validation\n- **Wrong data types**: Using VARCHAR instead of TEXT or CITEXT\n- **Missing JSONB structure**: Unstructured JSONB without validation\n\n### Function and Trigger Issues\n\n```sql\n-- ❌ BAD: Inefficient trigger function\nCREATE OR REPLACE FUNCTION update_modified_time()\nRETURNS TRIGGER AS $$\nBEGIN\n NEW.updated_at = NOW(); -- Should use TIMESTAMPTZ\n RETURN NEW;\nEND;\n$$ LANGUAGE plpgsql;\n\n-- ✅ GOOD: Optimized trigger function\nCREATE OR REPLACE FUNCTION update_modified_time()\nRETURNS TRIGGER AS $$\nBEGIN\n NEW.updated_at = CURRENT_TIMESTAMP;\n RETURN NEW;\nEND;\n$$ LANGUAGE plpgsql;\n\n-- Set trigger to fire only when needed\nCREATE TRIGGER update_modified_time_trigger\n BEFORE UPDATE ON table_name\n FOR EACH ROW\n WHEN (OLD.* IS DISTINCT FROM NEW.*)\n EXECUTE FUNCTION update_modified_time();\n```\n\n## 📊 PostgreSQL Extension Usage Review\n\n### Extension Best Practices\n\n```sql\n-- ✅ Check if extension exists before creating\nCREATE EXTENSION IF NOT EXISTS \"uuid-ossp\";\nCREATE EXTENSION IF NOT EXISTS \"pgcrypto\";\nCREATE EXTENSION IF NOT EXISTS \"pg_trgm\";\n\n-- ✅ Use extensions appropriately\n-- UUID generation\nSELECT uuid_generate_v4();\n\n-- Password hashing\nSELECT crypt('password', gen_salt('bf'));\n\n-- Fuzzy text matching\nSELECT word_similarity('postgres', 'postgre');\n```\n\n## 🛡️ PostgreSQL Security Review\n\n### Row Level Security (RLS)\n\n```sql\n-- ✅ GOOD: Implementing RLS\nALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;\n\nCREATE POLICY user_data_policy ON sensitive_data\n FOR ALL TO application_role\n USING (user_id = current_setting('app.current_user_id')::INTEGER);\n```\n\n### Privilege Management\n\n```sql\n-- ❌ BAD: Overly broad permissions\nGRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;\n\n-- ✅ GOOD: Granular permissions\nGRANT SELECT, INSERT, UPDATE ON specific_table TO app_user;\nGRANT USAGE ON SEQUENCE specific_table_id_seq TO app_user;\n```\n\n## 🎯 PostgreSQL Code Quality Checklist\n\n### Schema Design\n\n- [ ] Using appropriate PostgreSQL data types (CITEXT, JSONB, arrays)\n- [ ] Leveraging ENUM types for constrained values\n- [ ] Implementing proper CHECK constraints\n- [ ] Using TIMESTAMPTZ instead of TIMESTAMP\n- [ ] Defining custom domains for reusable constraints\n\n### Performance Considerations\n\n- [ ] Appropriate index types (GIN for JSONB/arrays, GiST for ranges)\n- [ ] JSONB queries using containment operators (@>, ?)\n- [ ] Array operations using PostgreSQL-specific operators\n- [ ] Proper use of window functions and CTEs\n- [ ] Efficient use of PostgreSQL-specific functions\n\n### PostgreSQL Features Utilization\n\n- [ ] Using extensions where appropriate\n- [ ] Implementing stored procedures in PL/pgSQL when beneficial\n- [ ] Leveraging PostgreSQL's advanced SQL features\n- [ ] Using PostgreSQL-specific optimization techniques\n- [ ] Implementing proper error handling in functions\n\n### Security and Compliance\n\n- [ ] Row Level Security (RLS) implementation where needed\n- [ ] Proper role and privilege management\n- [ ] Using PostgreSQL's built-in encryption functions\n- [ ] Implementing audit trails with PostgreSQL features\n\n## 📝 PostgreSQL-Specific Review Guidelines\n\n1. **Data Type Optimization**: Ensure PostgreSQL-specific types are used appropriately\n2. **Index Strategy**: Review index types and ensure PostgreSQL-specific indexes are utilized\n3. **JSONB Structure**: Validate JSONB schema design and query patterns\n4. **Function Quality**: Review PL/pgSQL functions for efficiency and best practices\n5. **Extension Usage**: Verify appropriate use of PostgreSQL extensions\n6. **Performance Features**: Check utilization of PostgreSQL's advanced features\n7. **Security Implementation**: Review PostgreSQL-specific security features\n\nFocus on PostgreSQL's unique capabilities and ensure the code leverages what makes PostgreSQL special rather than treating it as a generic SQL database.", "variables": [ "selection" ], "notes": "PostgreSQL-specific code review assistant focusing on PostgreSQL best practices, anti-patterns, and unique quality standards. Covers JSONB operations, array usage, custom types, schema design, function optimization, and PostgreSQL-exclusive security features like Row Level Security (RLS). Mode: agent. Tools: changes, codebase, edit/editFiles, problems.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/lightspeedwp/utils", "path": ".github/prompts/awesome-copilot/postgresql-code-review.prompt.md", "ref": "cd6f313161786a17f51718c94d58d65310f06e57", "url": "https://github.com/lightspeedwp/utils/blob/cd6f313161786a17f51718c94d58d65310f06e57/.github/prompts/awesome-copilot/postgresql-code-review.prompt.md", "key": "lightspeedwp/utils/.github/prompts/awesome-copilot/postgresql-code-review.prompt.md" } } }

postgresql-code-review

About