pg_Admin plugin

[ppKrauss]

Evaluate and formulate a project for pg_Admin integration with pg_govLite. Proposed scenario and features:

• ...

Requirements:

• Display of links or options for...
• ...

Aspects to evaluate:

• Does pgAdmin have a native extension/plugin feature?
• Complexity level of customizing pgAdmin to add links or menu items.
• Architectural options involving higher vs. lower degrees of coupling between pgAdmin and pg_govLite.

[ppKrauss]

Remember for render-table choice, https://docs.webix.com/datatable__sparklines.html

[brunoportess]

Scope Clarification — pgAdmin Integration with pg_govLite

To clarify the scope and align expectations for this task, the work discussed so far has evolved from an initial feasibility study into a more defined implementation direction.

1. Initial Goal

The original goal was to evaluate the best way to provide access to pg_govLite external data from within the same database administration environment used by the end user.

The options considered included:

• Customizing pgAdmin through a fork of the official project.
• Creating a separate portal/application to display pg_govLite information.
• Using alternatives such as FDW (Foreign Data Wrapper) or other lower-coupling approaches.
• Evaluating the level of effort, complexity, and maintainability of each option.

2. Selected Approach

After the initial analysis, the selected approach is to proceed with a custom fork of pgAdmin.

The objective is not to create a generic plugin framework for pgAdmin.

The implementation will be a specific custom module/plugin focused exclusively on integration with the pg_govLite PostgREST API.

The goal is to keep the standard pgAdmin functionality while adding a dedicated entry point for accessing pg_govLite information.

3. Expected POC/MVP

The proposed POC/MVP will cover:

1. Create and maintain a fork of the pgAdmin project.
2. Add a new menu option or dedicated module inside the pgAdmin interface.
3. From this module, perform calls to specific pg_govLite PostgREST endpoints.
4. Display the returned information inside the pgAdmin interface.
5. Allow the user to access both standard PostgreSQL administration and pg_govLite external information from the same tool.
6. Keep the custom implementation as isolated as possible from the pgAdmin core to reduce maintenance impact when updating the fork in the future.

The expected high-level flow is:

User
  │
  ▼
pgAdmin Web Interface
  │
  ├── Standard pgAdmin Features
  │
  └── pg_govLite Module / Menu
            │
            ▼
      pg_govLite PostgREST
            │
            ▼
      pg_govLite Data

4. Data Presentation

At this stage, the exact PostgREST response structure has not yet been provided, and the final presentation format of the returned data has not been defined.

Because of that, components such as:

• Data tables
• Charts
• Sparklines
• JSON views
• Maps or geographic visualizations
• Specific renderers such as the referenced Webix DataTable

should currently be considered implementation options rather than fixed requirements.

The final UI and rendering strategy can be defined after reviewing the available pg_govLite endpoints, their response payloads, and the expected user interaction.

Reference provided for table rendering:

https://docs.webix.com/datatable__sparklines.html

5. Deployment Model

The preferred deployment model for the POC/MVP is a Dockerized pgAdmin web version accessed through the browser.

This approach was selected because it provides a simpler model for:

• Centralized deployment
• Testing
• Versioning
• Configuration
• Updates
• Rollback
• Distribution of the custom pgAdmin version

This also avoids the additional complexity of maintaining custom desktop installers for different operating systems.

The expected deployment model is:

Browser
   │
   ▼
Custom pgAdmin Docker Container
   │
   ├── Standard pgAdmin
   │
   └── pg_govLite Custom Module
               │
               ▼
        pg_govLite PostgREST

6. Current Effort Allocation

The effort discussed for this work is currently:

Activity	Estimated / Allocated Hours
QGIS analysis/study	11h
Analysis of architectural options and available approaches	2h
Alignment meeting with Anderson	1h
pgAdmin custom fork + pg_govLite integration POC/MVP	50h
Total	64h

7. Scope of the 50-Hour POC/MVP Implementation

The 50-hour implementation estimate is intended to cover the initial working POC/MVP, including:

• pgAdmin fork setup.
• Custom module/plugin structure.
• New pgAdmin menu entry.
• Initial UI integrated into pgAdmin.
• Communication with pg_govLite PostgREST.
• Integration with the initially selected endpoint(s).
• Basic rendering of returned data.
• Configuration required for the external API.
• Basic authentication handling, if required by the API.
• Loading and error handling.
• Dockerized web/browser deployment.
• Testing and stabilization of the POC/MVP.

8. Important Scope Boundary

The current POC/MVP does not assume the development of:

• A generic pgAdmin plugin framework.
• A generic REST API client inside pgAdmin.
• Dynamic discovery of arbitrary APIs.
• Support for arbitrary PostgREST instances.
• A generic data visualization framework.
• A replacement for pgAdmin functionality.

The integration is specifically designed for:

pgAdmin → pg_govLite Module → pg_govLite PostgREST API

Additional endpoints, advanced visualization components, geographic rendering, complex permissions, or other features may be evaluated after the initial POC/MVP based on the actual pg_govLite API structure and business requirements.

9. Expected Deliverable

The primary deliverable is a working custom pgAdmin version demonstrating that pg_govLite data can be queried and displayed through a dedicated option inside the pgAdmin interface.

The POC/MVP should validate that:

• The pgAdmin fork can be built and maintained.
• A custom pg_govLite module/menu can be integrated.
• The module can communicate with the pg_govLite PostgREST API.
• Returned data can be displayed inside the pgAdmin interface.
• The customized version can be packaged and executed through Docker for browser-based access.

Once these points are validated, additional pg_govLite endpoints and richer visualization capabilities can be incrementally added to the custom module.