PostgREST / postgrest

REST API for any Postgres database
https://postgrest.org
MIT License
22.52k stars 996 forks source link

Support structured data in PostgreSQL `COMMENT`s #3487

Open salim-b opened 3 weeks ago

salim-b commented 3 weeks ago

Problem

PostgREST allows to specify additional metadata to document the offered RESTful API via PostgreSQL COMMENTs. Other tools also leverage PostgreSQL COMMENTs to specify additional metadata or configuration, e.g.

If one decides to use one of these tools in conjunction with PostgREST, conflicts arise, i.e. PostgREST won't ignore the above tags but include them in the generated OpenAPI description. The underlying problem could be summarized as the lack of a common standard to include structured data in PostgreSQL COMMENTs[^s].

Solution

In another discussion @wolfgangwalther suggested to

use a yaml front matter block to add metadata, while keeping the current openapi comments support backwards compatible

YAML headers seem powerful (e.g. multiple tools could read the same keys) and pragmatic at the same time (not too hard to parse and can be implemented in a backwards-compatible way), so other tools would hopefully add support for it, too. The author of pg_graphql already showed approval and would implement it. YAML headers would also allow to "hide" arbitrary data from PostgREST like the above @-tags by simply defining them inside the YAML header (under a key that has no meaning for PostgREST). In the end, the possible use cases go far beyond PostgREST – but PostgREST could lead the way!

[^s]: A web search did not reveal any kind of existing initiative to establish such a standard. Please correct me, if I missed something!

Preliminary discussion

Further notes

wolfgangwalther commented 3 weeks ago

A more principled approach to this problem would be to work towards a feature in PostgreSQL to support "namespaced comments". Those could work very similar to SECURITY LABEL FOR <provider> ON ..., which is very similar in syntax (and I think the underlying architecture) to COMMENT ON ....

If we had something like COMMENT FOR <tool> ON .. we'd be much better off, I think.