Extension vs Implementing Wire Protocol

From: Matthew Tamayo-Rios <matthew(at)openlattice(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Extension vs Implementing Wire Protocol
Date: 2020-07-20 20:13:04
Message-ID: CABMCe9Hjwdo362saHEdNRrR4gXKx3Z7e7LpNpCNc9wyneqpPzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all,

We need to apply some data management policies on read. We are considering
two approaches

1. Implement a postgres extension.
2. Implement a proxy that implements the PostgreSQL wire protocol.

We're trying to decide which approach to take and are leaning towards
implementing it as an open source extension. Mostly what we need is to be
able to apply simple row level transformations after query execution before
data is returned to the client. Our hope is we can do this without messing
with cursors or execution as we don't want it to be brittle across postgres
versions. It would be super cool if it could apply to foreign data wrappers
as well.

Examples of behaviors we'd like to have:

- 'SELECT * FROM table;' should return masked versions of the columns
based on policy for that specific user.
- 'SELECT * FROM table;' should return just the columns accessible to
a specific user.

Questions:

1. Are there easily extensible (ideally open-source) proxies that
already implement the Postgres protocol that we could modify/extend to
support this?
2. Does the extension framework support post-query execution
transformations before returning the result set such that it is compatible
with postgres clients (transparently).

This seems like a useful extension and we'd be happy to build it and open
source it so that other folks could benefit. Also, please let me know if I
got the wrong mailing list and should take discussion elsewhere.

Matthew

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2020-07-20 20:36:26 Re: Extension vs Implementing Wire Protocol
Previous Message John Ashmead 2020-07-20 18:11:24 Re: Logical replication from 11.x to 12.x and "unique key violations"