Fix spelling to satisfy postgrest-docs-spellcheck
This commit is contained in:
Wolfgang Walther
committed by
Wolfgang Walther
Wolfgang Walther
parent
84e5597091
commit
634a0c70b7
@@ -145,7 +145,7 @@ The PostgREST server logs basic request information to stdout, including the req
|
||||
HTTP Requests
|
||||
-------------
|
||||
|
||||
A great way to inspect incoming HTTP requests including headers and query params is to sniff the network traffic on the port where PostgREST is running. For instance on a development server bound to port 3000 on localhost, run this:
|
||||
A great way to inspect incoming HTTP requests including headers and query parameters is to sniff the network traffic on the port where PostgREST is running. For instance on a development server bound to port 3000 on localhost, run this:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
@@ -250,7 +250,7 @@ Now, whenever the structure of the database schema changes, PostgreSQL will noti
|
||||
Daemonizing
|
||||
===========
|
||||
|
||||
For linux distros that use **systemd** (ubuntu, debian, archlinux) you can create a daemon in the following way.
|
||||
For Linux distributions that use **systemd** (Ubuntu, Debian, Archlinux) you can create a daemon in the following way.
|
||||
|
||||
First, create postgrest configuration in ``/etc/postgrest/config``
|
||||
|
||||
@@ -271,7 +271,7 @@ Then create the systemd service file in ``/etc/systemd/system/postgrest.service`
|
||||
.. code-block:: ini
|
||||
|
||||
[Unit]
|
||||
Description=REST API for any Postgres database
|
||||
Description=REST API for any PostgreSQL database
|
||||
After=postgresql.service
|
||||
|
||||
[Service]
|
||||
|
||||
@@ -255,7 +255,7 @@ A full-text search on the computed column:
|
||||
|
||||
GET /people?full_name=fts.Beckett HTTP/1.1
|
||||
|
||||
As mentioned, computed columns do not appear in the output by default. However you can include them by listing them in the vertical filtering :code:`select` param:
|
||||
As mentioned, computed columns do not appear in the output by default. However you can include them by listing them in the vertical filtering :code:`select` parameter:
|
||||
|
||||
.. code-block:: HTTP
|
||||
|
||||
@@ -314,7 +314,7 @@ Here ``information.cpe`` is a column name.
|
||||
|
||||
.. note::
|
||||
|
||||
Some http libraries might encode URLs automatically(e.g. :code:`axios`). In these cases you should use double quotes
|
||||
Some HTTP libraries might encode URLs automatically(e.g. :code:`axios`). In these cases you should use double quotes
|
||||
:code:`""` directly instead of :code:`%22`.
|
||||
|
||||
Ordering
|
||||
@@ -332,7 +332,7 @@ If no direction is specified it defaults to ascending order:
|
||||
|
||||
GET /people?order=age HTTP/1.1
|
||||
|
||||
If you care where nulls are sorted, add nullsfirst or nullslast:
|
||||
If you care where nulls are sorted, add ``nullsfirst`` or ``nullslast``:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
@@ -359,7 +359,7 @@ PostgREST uses HTTP range headers to describe the size of results. Every respons
|
||||
|
||||
Here items zero through fourteen are returned. This information is available in every response and can help you render pagination controls on the client. This is an RFC7233-compliant solution that keeps the response JSON cleaner.
|
||||
|
||||
There are two ways to apply a limit and offset rows: through request headers or query params. When using headers you specify the range of rows desired. This request gets the first twenty people.
|
||||
There are two ways to apply a limit and offset rows: through request headers or query parameters. When using headers you specify the range of rows desired. This request gets the first twenty people.
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
@@ -443,7 +443,7 @@ To help with these cases, PostgREST can get the exact count up until a threshold
|
||||
that threshold is surpassed. To use this behavior, you can specify the ``Prefer: count=estimated`` header. The **threshold** is
|
||||
defined by :ref:`max-rows`.
|
||||
|
||||
Here's an example. Suppose we set ``max-rows=1000`` and *smalltable* has 321 rows, then we'll get the exact count:
|
||||
Here's an example. Suppose we set ``max-rows=1000`` and ``smalltable`` has 321 rows, then we'll get the exact count:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
@@ -455,7 +455,7 @@ Here's an example. Suppose we set ``max-rows=1000`` and *smalltable* has 321 row
|
||||
HTTP/1.1 206 Partial Content
|
||||
Content-Range: 0-24/321
|
||||
|
||||
If we make a similar request on *bigtable*, which has 3573458 rows, we would get the planned count:
|
||||
If we make a similar request on ``bigtable``, which has 3573458 rows, we would get the planned count:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
@@ -481,13 +481,13 @@ Use the Accept request header to specify the acceptable format (or formats) for
|
||||
GET /people HTTP/1.1
|
||||
Accept: application/json
|
||||
|
||||
The current possibilities are
|
||||
The current possibilities are:
|
||||
|
||||
* \*/\*
|
||||
* text/csv
|
||||
* application/json
|
||||
* application/openapi+json
|
||||
* application/octet-stream
|
||||
* ``*/*``
|
||||
* ``text/csv``
|
||||
* ``application/json``
|
||||
* ``application/openapi+json``
|
||||
* ``application/octet-stream``
|
||||
|
||||
The server will default to JSON for API endpoints and OpenAPI on the root.
|
||||
|
||||
@@ -776,7 +776,7 @@ Embedding Disambiguation
|
||||
------------------------
|
||||
|
||||
For doing resource embedding, PostgREST infers the relationship between two tables based on a foreign key between them.
|
||||
However, in cases where there's more than one foreign key between two tables, it's not possible to infer the relationship unambiguosly
|
||||
However, in cases where there's more than one foreign key between two tables, it's not possible to infer the relationship unambiguously
|
||||
by just specifying the tables names.
|
||||
|
||||
Target Disambiguation
|
||||
@@ -850,7 +850,7 @@ Hint Disambiguation
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If specifying the **target** is not enough for unambiguous embedding, you can add a **hint**. For example, let's assume we create
|
||||
two VIEWs of ``addresses``: ``central_addresses`` and ``eastern_addresses``.
|
||||
two views of ``addresses``: ``central_addresses`` and ``eastern_addresses``.
|
||||
|
||||
Since PostgREST supports :ref:`embedding_views` by detecting **source foreign keys** in the views, embedding with the foreign key
|
||||
as the **target** will not be enough for an unambiguous embed:
|
||||
@@ -914,7 +914,7 @@ URL encoded payloads can be posted with ``Content-Type: application/x-www-form-u
|
||||
No
|
||||
"{ \"a\": 1, \"b\": 2 }"
|
||||
|
||||
Some javascript libraries will post the data incorrectly if you're not careful. For best results try one of the :ref:`clientside_libraries` built for PostgREST.
|
||||
Some JavaScript libraries will post the data incorrectly if you're not careful. For best results try one of the :ref:`clientside_libraries` built for PostgREST.
|
||||
|
||||
To update a row or rows in a table, use the PATCH verb. Use :ref:`h_filter` to specify which record(s) to update. Here is an example query setting the :code:`category` column to child for all people below a certain age.
|
||||
|
||||
@@ -1150,7 +1150,7 @@ PostgreSQL has four procedural languages that are part of the core distribution:
|
||||
|
||||
.. note::
|
||||
|
||||
Why the `/rpc` prefix? One reason is to avoid name collisions between views and procedures. It also helps emphasize to API consumers that these functions are not normal restful things. The functions can have arbitrary and surprising behavior, not the standard "post creates a resource" thing that users expect from the other routes.
|
||||
Why the ``/rpc`` prefix? One reason is to avoid name collisions between views and procedures. It also helps emphasize to API consumers that these functions are not normal restful things. The functions can have arbitrary and surprising behavior, not the standard "post creates a resource" thing that users expect from the other routes.
|
||||
|
||||
Immutable and stable functions
|
||||
------------------------------
|
||||
@@ -1171,10 +1171,10 @@ Because ``add_them`` is ``IMMUTABLE``, we can alternately call the function with
|
||||
|
||||
The function parameter names match the JSON object keys in the POST case, for the GET case they match the query parameters ``?a=1&b=2``.
|
||||
|
||||
Calling functions with a single json parameter
|
||||
Calling functions with a single JSON parameter
|
||||
----------------------------------------------
|
||||
|
||||
You can also call a function that takes a single parameter of type json by sending the header :code:`Prefer: params=single-object` with your request. That way the JSON request body will be used as the single argument.
|
||||
You can also call a function that takes a single parameter of type JSON by sending the header :code:`Prefer: params=single-object` with your request. That way the JSON request body will be used as the single argument.
|
||||
|
||||
.. code-block:: plpgsql
|
||||
|
||||
@@ -1220,7 +1220,7 @@ as in ``{1,2,3,4}``. Note that the curly brackets have to be urlencoded(``{`` is
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
GET /rpc/plus_one?arr=%7B1,2,3,4%7D' HTTP/1.1
|
||||
GET /rpc/plus_one?arr=%7B1,2,3,4%7D' HTTP/1.1
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -1232,14 +1232,14 @@ as in ``{1,2,3,4}``. Note that the curly brackets have to be urlencoded(``{`` is
|
||||
|
||||
{ "arr": "{1,2,3,4}" }
|
||||
|
||||
In these versions we recommend using function parameters of type json to accept arrays from the client.
|
||||
In these versions we recommend using function parameters of type JSON to accept arrays from the client.
|
||||
|
||||
.. _s_procs_variadic:
|
||||
|
||||
Calling variadic functions
|
||||
--------------------------
|
||||
|
||||
You can call a variadic function by passing a json array in a POST request:
|
||||
You can call a variadic function by passing a JSON array in a POST request:
|
||||
|
||||
.. code-block:: postgres
|
||||
|
||||
@@ -1299,7 +1299,7 @@ PostgREST will detect if the function is scalar or table-valued and will shape t
|
||||
Bulk Call
|
||||
---------
|
||||
|
||||
It's possible to call a function in a bulk way, analoguosly to :ref:`bulk_insert`. To do this, you need to add the
|
||||
It's possible to call a function in a bulk way, analogously to :ref:`bulk_insert`. To do this, you need to add the
|
||||
``Prefer: params=multiple-objects`` header to your request.
|
||||
|
||||
.. code-block:: http
|
||||
@@ -1316,7 +1316,7 @@ It's possible to call a function in a bulk way, analoguosly to :ref:`bulk_insert
|
||||
|
||||
[ 3, 7 ]
|
||||
|
||||
If you have large payloads to process, it's preferrable you instead use a function with an :ref:`array parameter <s_procs_array>` or json parameter, as this will be more efficient.
|
||||
If you have large payloads to process, it's preferable you instead use a function with an :ref:`array parameter <s_procs_array>` or JSON parameter, as this will be more efficient.
|
||||
|
||||
It's also possible to :ref:`Specify Columns <specify_columns>` on functions calls.
|
||||
|
||||
@@ -1489,7 +1489,7 @@ HTTP Logic
|
||||
Accessing Request Headers, Cookies and JWT claims
|
||||
-------------------------------------------------
|
||||
|
||||
You can access request headers, cookies and jwt claims by reading GUC variables set by PostgREST per request. They are named :code:`request.header.XYZ`, :code:`request.cookie.XYZ` and :code:`request.jwt.claim.XYZ`.
|
||||
You can access request headers, cookies and JWT claims by reading GUC variables set by PostgREST per request. They are named :code:`request.header.XYZ`, :code:`request.cookie.XYZ` and :code:`request.jwt.claim.XYZ`.
|
||||
|
||||
.. code-block:: postgresql
|
||||
|
||||
@@ -1707,7 +1707,7 @@ PostgREST translates `PostgreSQL error codes <https://www.postgresql.org/docs/cu
|
||||
+--------------------------+-------------------------+---------------------------------+
|
||||
| 58* | 500 | system error |
|
||||
+--------------------------+-------------------------+---------------------------------+
|
||||
| F0* | 500 | conf file error |
|
||||
| F0* | 500 | config file error |
|
||||
+--------------------------+-------------------------+---------------------------------+
|
||||
| HV* | 500 | foreign data wrapper error |
|
||||
+--------------------------+-------------------------+---------------------------------+
|
||||
|
||||
@@ -182,7 +182,7 @@ Next write a stored procedure that returns the token. The one below returns a to
|
||||
) r;
|
||||
$$ LANGUAGE sql;
|
||||
|
||||
PostgREST exposes this function to clients via a POST request to `/rpc/jwt_test`.
|
||||
PostgREST exposes this function to clients via a POST request to ``/rpc/jwt_test``.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
+7
-7
@@ -30,9 +30,9 @@ The user specified in the db-uri is also known as the authenticator role. For mo
|
||||
|
||||
Here is the full list of configuration parameters.
|
||||
|
||||
======================== ====== ========= ========
|
||||
======================== ======= ========= ========
|
||||
Name Type Default Required
|
||||
======================== ====== ========= ========
|
||||
======================== ======= ========= ========
|
||||
db-uri String Y
|
||||
db-schema String Y
|
||||
db-anon-role String Y
|
||||
@@ -43,16 +43,16 @@ server-host String !4
|
||||
server-port Int 3000
|
||||
server-unix-socket String
|
||||
server-unix-socket-mode String 660
|
||||
openapi-server-proxy-uri String
|
||||
openapi-server-proxy-uri String
|
||||
jwt-secret String
|
||||
jwt-aud String
|
||||
secret-is-base64 Bool False
|
||||
secret-is-base64 Boolean False
|
||||
max-rows Int ∞
|
||||
pre-request String
|
||||
app.settings.* String
|
||||
role-claim-key String .role
|
||||
raw-media-types String
|
||||
======================== ====== ========= ========
|
||||
======================== ======= ========= ========
|
||||
|
||||
.. _db-uri:
|
||||
|
||||
@@ -266,8 +266,8 @@ raw-media-types
|
||||
|
||||
These media types can be requested by following the same rules as the ones defined in :ref:`binary_output`.
|
||||
|
||||
As an example, the below config would allow you to request an **image** and an **xml** by doing a request with ``Accept: image/png``
|
||||
and a request with ``Accept: text/xml``, respectively.
|
||||
As an example, the below config would allow you to request an **image** and a **XML** file by doing a request with ``Accept: image/png``
|
||||
or ``Accept: text/xml``, respectively.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
|
||||
+4
-4
@@ -41,18 +41,18 @@ To help with development, you'll need to build from source. `Stack <https://gith
|
||||
Running the Test Suite
|
||||
======================
|
||||
|
||||
To properly run the test suite, you need a Postgres database that the tests can run against. There are several ways to set up this database.
|
||||
To properly run the test suite, you need a PostgreSQL database that the tests can run against. There are several ways to set up this database.
|
||||
|
||||
Testing with a temporary database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you have Postgres installed locally (:code:`initdb`, :code:`pg_ctl` and :code:`psql` should be on your PATH, no server needs to be running), you can run the test suite against a temporary database:
|
||||
If you have PostgreSQL installed locally (:code:`initdb`, :code:`pg_ctl` and :code:`psql` should be on your PATH, no server needs to be running), you can run the test suite against a temporary database:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
test/with_tmp_db stack test
|
||||
|
||||
The :code:`with_tmp_db` script will set up a new Postgres cluster in a temporary directory, set the required environment variables and run the command that you passed it as an argument, :code:`stack test` in the example above. When the command is done, the temporary database is torn down and deleted again.
|
||||
The :code:`with_tmp_db` script will set up a new PostgreSQL cluster in a temporary directory, set the required environment variables and run the command that you passed it as an argument, :code:`stack test` in the example above. When the command is done, the temporary database is torn down and deleted again.
|
||||
|
||||
Manually creating the Test Database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -84,7 +84,7 @@ Running the Tests with the manually created database
|
||||
|
||||
To run the tests, one must supply the database uri in the environment variable :code:`POSTGREST_TEST_CONNECTION`.
|
||||
|
||||
Typically, one would create the database and run the test in the same command line, using the `postgres` superuser:
|
||||
Typically, one would create the database and run the test in the same command line, using the ``postgres`` superuser:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
|
||||
+10
-10
@@ -6,7 +6,7 @@ Community Tutorials
|
||||
* `Building a Contacts List with PostgREST and Vue.js <https://www.youtube.com/watch?v=iHtsALtD5-U>`_ -
|
||||
In this video series, DigitalOcean shows how to build and deploy an Nginx + PostgREST(using a managed PostgreSQL database) + Vue.js webapp in an Ubuntu server droplet.
|
||||
|
||||
* `PostgREST + Auth0: Create REST API in mintutes, and add social login using Auth0 <https://samkhawase.com/blog/postgrest/>`_ - A step-by-step tutorial to show how to Dockerize and integrate Auth0 to PostgREST service.
|
||||
* `PostgREST + Auth0: Create REST API in mintutes, and add social login using Auth0 <https://samkhawase.com/blog/postgrest/>`_ - A step-by-step tutorial to show how to dockerize and integrate Auth0 to PostgREST service.
|
||||
|
||||
* `PostgREST + PostGIS API tutorial in 5 minutes <https://gis-ops.com/postgrest-postgis-api-tutorial-geospatial-api-in-5-minutes/>`_ -
|
||||
In this tutorial, GIS • OPS shows how to perform PostGIS calculations through PostgREST :ref:`s_procs` interface.
|
||||
@@ -23,10 +23,10 @@ Example Apps
|
||||
* `tatut/postgrest-ui <https://github.com/tatut/postgrest-ui>`_ - ClojureScript UI components for PostgREST
|
||||
* `priyank-purohit/PostGUI <https://github.com/priyank-purohit/PostGUI>`_ - React Material UI admin panel
|
||||
* `Qu4tro/pgrst-dev-setup <https://github.com/Qu4tro/pgrst-dev-setup>`_ - docker-compose and tmuxp setup for experimentation.
|
||||
* `subzerocloud/postgrest-starter-kit <https://github.com/subzerocloud/postgrest-starter-kit>`_ - Boilerplate for new project
|
||||
* `NikolayS/postgrest-google-translate <https://github.com/NikolayS/postgrest-google-translate>`_ - Calling to external translation service
|
||||
* `subzerocloud/postgrest-starter-kit <https://github.com/subzerocloud/postgrest-starter-kit>`_ - boilerplate for new project
|
||||
* `NikolayS/postgrest-google-translate <https://github.com/NikolayS/postgrest-google-translate>`_ - calling to external translation service
|
||||
* `CodeforAustralia/heritage-near-me <https://github.com/CodeforAustralia/heritage-near-me>`_ - Elm and PostgREST with PostGIS
|
||||
* `timwis/handsontable-postgrest <https://github.com/timwis/handsontable-postgrest>`_ - An excel-like database table editor
|
||||
* `timwis/handsontable-postgrest <https://github.com/timwis/handsontable-postgrest>`_ - an excel-like database table editor
|
||||
* `Recmo/PostgrestSkeleton <https://github.com/Recmo/PostgrestSkeleton>`_ - Docker Compose, PostgREST, Nginx and Auth0
|
||||
* `benoror/ember-postgrest-dynamic-ui <https://github.com/benoror/ember-postgrest-dynamic-ui>`_ - generating Ember forms to edit data
|
||||
* `ruslantalpa/blogdemo <https://github.com/ruslantalpa/blogdemo>`_ - blog api demo in a vagrant image
|
||||
@@ -39,7 +39,7 @@ Example Apps
|
||||
* `SMRxT/postgrest-demo <https://github.com/SMRxT/postgrest-demo>`_ - multi-tenant logging system
|
||||
* `PierreRochard/postgrest-boilerplate <https://github.com/PierreRochard/postgrest-boilerplate>`_ - example auth back-end
|
||||
* `marmelab/ng-admin-postgrest <https://github.com/marmelab/ng-admin-postgrest>`_ - automatic database admin panel
|
||||
* `seveibar/postgrest-vercel <https://github.com/seveibar/postgrest-vercel>`_ - Run postgrest on Vercel (Serverless/AWS Lambda)
|
||||
* `seveibar/postgrest-vercel <https://github.com/seveibar/postgrest-vercel>`_ - run PostgREST on Vercel (Serverless/AWS Lambda)
|
||||
|
||||
.. _eco_external_notification:
|
||||
|
||||
@@ -48,7 +48,7 @@ External Notification
|
||||
|
||||
These are PostgreSQL bridges that propagate LISTEN/NOTIFY to external queues for further processing. This allows stored procedures to initiate actions outside the database such as sending emails.
|
||||
|
||||
* `vbalasu/pg-notify-webhook <https://pypi.org/project/pg-notify-webhook/>`_ - Trigger webhooks from postgres LISTEN/NOTIFY
|
||||
* `vbalasu/pg-notify-webhook <https://pypi.org/project/pg-notify-webhook/>`_ - trigger webhooks from PostgreSQL's LISTEN/NOTIFY
|
||||
* `diogob/postgres-websockets <https://github.com/diogob/postgres-websockets>`_ - expose web sockets for PostgreSQL's LISTEN/NOTIFY
|
||||
* `frafra/postgresql2websocket <https://github.com/frafra/postgresql2websocket>`_ - Websockets
|
||||
* `matthewmueller/pg-bridge <https://github.com/matthewmueller/pg-bridge>`_ - Amazon SNS
|
||||
@@ -63,14 +63,14 @@ These are PostgreSQL bridges that propagate LISTEN/NOTIFY to external queues for
|
||||
Extensions
|
||||
----------
|
||||
|
||||
* `pg-safeupdate <https://github.com/eradman/pg-safeupdate>`_ - Prevent full-table updates or deletes
|
||||
* `pg-safeupdate <https://github.com/eradman/pg-safeupdate>`_ - prevent full-table updates or deletes
|
||||
* `srid/spas <https://github.com/srid/spas>`_ - allow file uploads and basic auth
|
||||
* `svmnotn/postgrest-auth <https://github.com/svmnotn/postgrest-auth>`_ - OAuth2-inspired external auth server
|
||||
* `wildsurfer/postgrest-oauth-server <https://github.com/wildsurfer/postgrest-oauth-server>`_ - OAuth2 server
|
||||
* `nblumoe/postgrest-oauth <https://github.com/nblumoe/postgrest-oauth>`_ - OAuth2 WAI middleware
|
||||
* `criles25/postgrest-auth <https://github.com/criles25/postgrest-auth>`_ - email based auth/signup
|
||||
* `ppKrauss/PostgREST-writeAPI <https://github.com/ppKrauss/PostgREST-writeAPI>`_ - generate Nginx rewrite rules to fit an OpenAPI spec
|
||||
* `seveibar/postgrest-node <https://github.com/seveibar/postgrest-node>`_ - Run a postgrest server in NodeJS via an npm module
|
||||
* `ppKrauss/PostgREST-writeAPI <https://github.com/ppKrauss/PostgREST-writeAPI>`_ - generate nginx rewrite rules to fit an OpenAPI spec
|
||||
* `seveibar/postgrest-node <https://github.com/seveibar/postgrest-node>`_ - Run a PostgREST server in Node.js via npm module
|
||||
* `Exahilosys/aiodata <https://github.com/Exahilosys/aiodata>`_ - Python, event-based proxy and caching client.
|
||||
|
||||
.. _clientside_libraries:
|
||||
@@ -95,7 +95,7 @@ Client-Side Libraries
|
||||
* `clesiemo3/postgrestR <https://github.com/clesiemo3/postgrestR>`_ - R
|
||||
* `PierreRochard/postgrest-angular <https://github.com/PierreRochard/postgrest-angular>`_ - TypeScript, generate UI from API description
|
||||
* `thejettdurham/postgrest-sharp-client <https://github.com/thejettdurham/postgrest-sharp-client>`_ (needs maintainer) - C#, RestSharp
|
||||
* `team142/ng-postgrest <https://github.com/team142/ng-postgrest>`_ - Angular app for browsing, editing data exposed over Postgrest.
|
||||
* `team142/ng-postgrest <https://github.com/team142/ng-postgrest>`_ - Angular app for browsing, editing data exposed over PostgREST.
|
||||
* `andytango/redux-postgrest <https://github.com/andytango/redux-postgrest>`_ - TypeScript/JS, client integrated with (React) Redux.
|
||||
|
||||
.. _eco_commercial:
|
||||
|
||||
@@ -80,12 +80,12 @@ The result now is:
|
||||
}
|
||||
]
|
||||
|
||||
You can use the same idea for creating custom CASTs for different types.
|
||||
You can use the same idea for creating custom casts for different types.
|
||||
|
||||
.. note::
|
||||
|
||||
If you don't want to modify CASTs for built-in types, an option would be to `create a custom type <https://www.postgresql.org/docs/current/sql-createtype.html>`_
|
||||
for your own ``tsrange`` and add its own CAST.
|
||||
If you don't want to modify casts for built-in types, an option would be to `create a custom type <https://www.postgresql.org/docs/current/sql-createtype.html>`_
|
||||
for your own ``tsrange`` and add its own cast.
|
||||
|
||||
.. code-block:: postgres
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
.. _providing_img:
|
||||
|
||||
Providing images for <img>
|
||||
==========================
|
||||
Providing images for ``<img>``
|
||||
==============================
|
||||
|
||||
:author: `pkel <https://github.com/pkel>`_
|
||||
|
||||
In this how-to, you will learn how to create an endpoint for providing images to HTML :code:`<img>` tags without client side javascript.
|
||||
In this how-to, you will learn how to create an endpoint for providing images to HTML :code:`<img>` tags without client side JavaScript.
|
||||
The resulting HTML might look like this:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
@@ -238,7 +238,7 @@ Testimonials
|
||||
-- Louis Brauer
|
||||
|
||||
"I really enjoyed the fact that all of a sudden I was writing
|
||||
microservices in SQL DDL (and v8 javascript functions). I dodged so
|
||||
microservices in SQL DDL (and v8 JavaScript functions). I dodged so
|
||||
much boilerplate. The next thing I knew, we pulled out a full rewrite
|
||||
of a Spring+MySQL legacy app in 6 months. Literally 10x faster, and
|
||||
code was super concise. The old one took 3 years and a team of 4
|
||||
|
||||
+2
-2
@@ -51,7 +51,7 @@ If you downloaded PostgREST from the release page, first extract the compressed
|
||||
|
||||
# On Windows you should unzip the file
|
||||
|
||||
Now you can run postgrest with the :code:`--help` flag to see usage instructions:
|
||||
Now you can run PostgREST with the :code:`--help` flag to see usage instructions:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -218,7 +218,7 @@ Assuming your making modifications locally and then pushing to GitHub, it's easy
|
||||
1. Create a new app on Heroku
|
||||
2. In Settings add the following buildpack :code:`https://github.com/PostgREST/postgrest-heroku`
|
||||
3. Add the require Config Vars in Heroku (see https://github.com/PostgREST/postgrest/blob/master/app.json#L7-L57 for more details)
|
||||
4. Modify your postgrest.conf file as required to match your Config Vars in Heroku
|
||||
4. Modify your ``postgrest.conf`` file as required to match your Config Vars in Heroku
|
||||
5. Create your :code:`Procfile` and add :code:`./env-to-config ./postgrest postgrest.conf`
|
||||
6. Push your changes to GitHub
|
||||
7. Set Heroku to automatically deploy from Master and then manually deploy the branch for the first build
|
||||
|
||||
+48
-13
@@ -1,24 +1,35 @@
|
||||
personal_ws-1.1 en 0 utf-8
|
||||
Adossi
|
||||
AMQP
|
||||
api
|
||||
API's
|
||||
Archlinux
|
||||
aud
|
||||
Auth
|
||||
auth
|
||||
authenticator
|
||||
balancer
|
||||
Bool
|
||||
Beles
|
||||
Bouscal
|
||||
buildpack
|
||||
cd
|
||||
centric
|
||||
conf
|
||||
changelog
|
||||
ClojureScript
|
||||
config
|
||||
cryptographically
|
||||
CSV
|
||||
csv
|
||||
Daemonizing
|
||||
DDL
|
||||
DiBiase
|
||||
disjoined
|
||||
dockerize
|
||||
DoS
|
||||
eq
|
||||
Fenko
|
||||
Fernandes
|
||||
filename
|
||||
FreeBSD
|
||||
fts
|
||||
GHC
|
||||
Github
|
||||
@@ -27,23 +38,24 @@ grantor
|
||||
GraphQL
|
||||
gte
|
||||
GUC
|
||||
Gumbs
|
||||
Haskell
|
||||
Heroku
|
||||
HMAC
|
||||
Homebrew
|
||||
http
|
||||
HTTPS
|
||||
HV
|
||||
ILIKE
|
||||
ilike
|
||||
io
|
||||
IP
|
||||
JS
|
||||
js
|
||||
JSON
|
||||
json
|
||||
JWK
|
||||
JWT
|
||||
jwt
|
||||
Kinesis
|
||||
Kofi
|
||||
localhost
|
||||
login
|
||||
Logins
|
||||
@@ -51,31 +63,36 @@ logins
|
||||
lon
|
||||
lt
|
||||
lte
|
||||
macOS
|
||||
middleware
|
||||
misprediction
|
||||
Mithril
|
||||
multi
|
||||
MVCC
|
||||
namespace
|
||||
namespaced
|
||||
neq
|
||||
NGINX
|
||||
Nginx
|
||||
nginx
|
||||
ngrep
|
||||
nullsfirst
|
||||
nullslast
|
||||
nixpkgs
|
||||
npm
|
||||
nxl
|
||||
nxr
|
||||
OAuth
|
||||
onwards
|
||||
OpenAPI
|
||||
openapi
|
||||
ORM
|
||||
ov
|
||||
param
|
||||
params
|
||||
passphrase
|
||||
Pelletier
|
||||
Petr
|
||||
pgcrypto
|
||||
pgjwt
|
||||
pgSQL
|
||||
phfts
|
||||
phraseto
|
||||
plainto
|
||||
plfts
|
||||
PostGIS
|
||||
PostgreSQL
|
||||
@@ -84,18 +101,24 @@ PostgREST
|
||||
postgrest
|
||||
PostgREST's
|
||||
pre
|
||||
psql
|
||||
Qin
|
||||
RabbitMQ
|
||||
Rafaj
|
||||
RDS
|
||||
reallyreallyreallyreallyverysafe
|
||||
Redux
|
||||
refactor
|
||||
requester's
|
||||
RESTful
|
||||
RestSharp
|
||||
RLS
|
||||
RPC
|
||||
RSA
|
||||
savepoint
|
||||
schemas
|
||||
Sencha
|
||||
Serverless
|
||||
SHA
|
||||
signup
|
||||
SIGUSR
|
||||
@@ -108,23 +131,35 @@ sr
|
||||
SSL
|
||||
stateful
|
||||
stdout
|
||||
Stolarz
|
||||
SuperAgent
|
||||
syslog
|
||||
systemd
|
||||
Tcl
|
||||
tmuxp
|
||||
todo
|
||||
todos
|
||||
Tsingson
|
||||
tsquery
|
||||
TypeScript
|
||||
UI
|
||||
ui
|
||||
unicode
|
||||
unix
|
||||
UPSERT
|
||||
Upsert
|
||||
uri
|
||||
url
|
||||
urls
|
||||
variadic
|
||||
Vercel
|
||||
verifier
|
||||
versioning
|
||||
Vondra
|
||||
Vue
|
||||
WAI
|
||||
webhooks
|
||||
websearch
|
||||
Websockets
|
||||
webuser
|
||||
wfts
|
||||
ZeroMQ
|
||||
|
||||
@@ -10,7 +10,7 @@ These are changes yet unreleased. If you'd like to try them out before a new off
|
||||
Added
|
||||
-----
|
||||
|
||||
* Allow http status override through the :ref:`response.status <guc_resp_status>` GUC.
|
||||
* Allow HTTP status override through the :ref:`response.status <guc_resp_status>` GUC.
|
||||
|br| -- `@steve-chavez <https://github.com/steve-chavez>`_
|
||||
* Allow :ref:`s_procs_variadic`.
|
||||
|br| -- `@wolfgangwalther <https://github.com/wolfgangwalther>`_
|
||||
@@ -24,6 +24,6 @@ Fixed
|
||||
Changed
|
||||
-------
|
||||
|
||||
* Docker images are now optimized to be built from the scratch image. This reduces the compressed image size from over 30mb to about 4mb.
|
||||
* Docker images are now optimized to be built from the scratch image. This reduces the compressed image size from over 30 MB to about 4 MB.
|
||||
For more details, see `Docker image built with Nix <https://github.com/PostgREST/postgrest/tree/master/nix/docker#docker-image-built-with-nix>`_.
|
||||
|br| -- `@monacoremo <https://github.com/monacoremo>`_
|
||||
|
||||
+2
-2
@@ -5,7 +5,7 @@
|
||||
v7.0.0
|
||||
======
|
||||
|
||||
You can donwload this release at the `PostgREST v7.0.0 release page <https://github.com/PostgREST/postgrest/releases/tag/v7.0.0>`_.
|
||||
You can download this release at the `PostgREST v7.0.0 release page <https://github.com/PostgREST/postgrest/releases/tag/v7.0.0>`_.
|
||||
|
||||
Added
|
||||
-----
|
||||
@@ -45,7 +45,7 @@ Added
|
||||
Fixed
|
||||
-----
|
||||
|
||||
* Allow embedding a VIEW when its source table foreign key is UNIQUE
|
||||
* Allow embedding a view when its source table foreign key is UNIQUE
|
||||
|br| -- `@bwbroersma <https://github.com/bwbroersma>`_
|
||||
|
||||
* ``Accept: application/vnd.pgrst.object+json`` behavior is now enforced for POST/PATCH/DELETE regardless of ``Prefer: return=minimal``
|
||||
|
||||
@@ -20,7 +20,7 @@ This allows you to change the internals of your schema and maintain backwards co
|
||||
Functions
|
||||
=========
|
||||
|
||||
By default, when a function is created, the privilege to execute it is not restricted by role. The function access is PUBLIC—executable by all roles (more details at `PostgreSQL Privileges page <https://www.postgresql.org/docs/12/ddl-priv.html>`_). This is not ideal for an API schema. To disable this behavior, you can run the following SQL statement:
|
||||
By default, when a function is created, the privilege to execute it is not restricted by role. The function access is ``PUBLIC`` — executable by all roles (more details at `PostgreSQL Privileges page <https://www.postgresql.org/docs/12/ddl-priv.html>`_). This is not ideal for an API schema. To disable this behavior, you can run the following SQL statement:
|
||||
|
||||
.. code-block:: postgres
|
||||
|
||||
@@ -55,7 +55,7 @@ Security definer
|
||||
----------------
|
||||
|
||||
A function is executed with the privileges of the user who calls it. This means that the user has to have all permissions to do the operations the procedure performs.
|
||||
If the function accesses private database objects, your :ref:`API roles <roles>` won't be able to succesfully execute the function.
|
||||
If the function accesses private database objects, your :ref:`API roles <roles>` won't be able to successfully execute the function.
|
||||
|
||||
Another option is to define the function with the :code:`SECURITY DEFINER` option. Then only one permission check will take place, the permission to call the function, and the operations in the function will have the authority of the user who owns the function itself.
|
||||
|
||||
@@ -84,13 +84,13 @@ For changing this, we can create a non-SUPERUSER role and make this role the vie
|
||||
|
||||
.. code-block:: postgres
|
||||
|
||||
CREATE ROLE api_views_owner NOINHERIT;
|
||||
ALTER VIEW sample_view OWNER TO api_views_owner;
|
||||
CREATE ROLE api_views_owner NOINHERIT;
|
||||
ALTER VIEW sample_view OWNER TO api_views_owner;
|
||||
|
||||
Rules
|
||||
-----
|
||||
|
||||
Insertion on VIEWs with complex `RULEs <https://www.postgresql.org/docs/11/sql-createrule.html>`_ might not work out of the box with PostgREST.
|
||||
It's recommended that you `use triggers instead of RULEs <https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules>`_.
|
||||
If you want to keep using RULEs, a workaround is to wrap the VIEW insertion in a stored procedure and call it through the :ref:`s_procs` interface.
|
||||
Insertion on views with complex `rules <https://www.postgresql.org/docs/11/sql-createrule.html>`_ might not work out of the box with PostgREST.
|
||||
It's recommended that you `use triggers instead of rules <https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules>`_.
|
||||
If you want to keep using rules, a workaround is to wrap the view insertion in a stored procedure and call it through the :ref:`s_procs` interface.
|
||||
For more details, see this `github issue <https://github.com/PostgREST/postgrest/issues/1283>`_.
|
||||
|
||||
Reference in New Issue
Block a user