docs: functions -> custom functions

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6244
GitOrigin-RevId: 999517c28791a0b8f3de1843f02232338ad00fa9
This commit is contained in:
Gil Mizrahi 2022-10-07 22:22:15 +03:00 committed by hasura-bot
parent 6f6177db38
commit 4a321e2459
13 changed files with 22 additions and 22 deletions

View File

@ -16,7 +16,7 @@ keywords:
**computed field** is an extra field added to a table, its value is
computed via an SQL function which has the table row type as an input
argument. Currenty, the Hasura GraphQL engine supports functions
argument. Currenty, the Hasura GraphQL engine supports custom functions
returning [base types](https://www.postgresql.org/docs/current/extend-type-system.mdx#id-1.8.3.5.9)
or [table row types](https://www.postgresql.org/docs/current/rowtypes.mdx#ROWTYPES-DECLARING) as computed fields.

View File

@ -30,7 +30,7 @@ replaces the older [schema/metadata API](/api-reference/schema-metadata-api/inde
`pg_track_function` is used to add a custom SQL function to the GraphQL
schema. It supports more configuration options than v1, and also
supports tracking functions as mutations. Also refer a note
supports tracking custom functions as mutations. Also refer a note
[here](/api-reference/syntax-defs.mdx#function-req-note).
Track an SQL function called `search_articles` with a Hasura session argument:

View File

@ -54,7 +54,7 @@ Each ✅ below links **directly** to the feature within a particular type of dat
| Table Relationships | [✅](/schema/postgres/table-relationships/index.mdx) | [✅](/schema/postgres/table-relationships/index.mdx) | [✅](/schema/ms-sql-server/table-relationships/index.mdx) | [✅](/schema/bigquery/table-relationships/index.mdx) |
| Remote Relationships | [✅](/schema/postgres/remote-relationships/index.mdx) | [✅](/schema/postgres/remote-relationships/index.mdx) | [✅](/schema/ms-sql-server/remote-relationships/index.mdx) | [✅](/schema/bigquery/index.mdx) |
| Views | [✅](/schema/postgres/views.mdx) | [✅](/schema/postgres/views.mdx) | [✅](/schema/ms-sql-server/views.mdx) | ❌ |
| Functions | [✅](/schema/postgres/custom-functions.mdx) | [✅](/schema/postgres/custom-functions.mdx) | ❌ | ❌ |
| Custom Functions | [✅](/schema/postgres/custom-functions.mdx) | [✅](/schema/postgres/custom-functions.mdx) | ❌ | ❌ |
| Enums | [✅](/schema/postgres/enums.mdx) | [✅](/schema/postgres/enums.mdx) | ❌ | ❌ |
| Computed Fields | [✅](/schema/postgres/computed-fields.mdx) | [✅](/schema/postgres/computed-fields.mdx) | ❌ | [✅](/schema/bigquery/computed-fields.mdx) |
| Data Validations | [✅](/schema/postgres/data-validations.mdx) | [✅](/schema/postgres/data-validations.mdx) | ✅ | [✅](/schema/bigquery/data-validations.mdx) |

View File

@ -39,7 +39,7 @@ Hasura currently supports queries, subscriptions, mutations, relationships and p
Next up on our roadmap for Hasura + SQL Server:
- Support for stored procedures & functions ([#7073](https://github.com/hasura/graphql-engine/issues/7073))
- Support for stored procedures & custom functions ([#7073](https://github.com/hasura/graphql-engine/issues/7073))
- Event triggers: Trigger HTTP webhooks with atomic capture and atleast once guarantee whenever data changes inside the
database ([#7075](https://github.com/hasura/graphql-engine/issues/7075))
- Remote Joins: Join models in SQL Server to models from other API services (GraphQL or REST)

View File

@ -104,7 +104,7 @@ creating a GraphQL query.
## Keep up to date
Hasura supports queries, relationships, permissions, functions and mutations on Citus.
Hasura supports queries, relationships, permissions, custom functions and mutations on Citus.
Please watch this space to get the latest docs on how you can try these features out via the console or by manipulating
metadata in JSON/YAML directly.

View File

@ -70,9 +70,9 @@ logic providers to your GraphQL API.
- Read more about [Remote Schemas](/remote-schemas/index.mdx)
**Stored procedures / functions in the database:** Stored procedures and functions are a common way to write and store
**Stored procedures / custom functions in the database:** Stored procedures and custom functions are a common way to write and store
high-performance business logic, or transactional logic, that's close to the data. As a part of the GraphQL API that
Hasura exposes over databases, Hasura allows you to expose stored procedures or functions as fields in the GraphQL
Hasura exposes over databases, Hasura allows you to expose stored procedures or custom functions as fields in the GraphQL
schema. This is a great way to bring in existing business logic that maybe in your database, or to write custom,
high-performance logic if youre familiar with databases!

View File

@ -1,5 +1,5 @@
---
description: Use Postgres functions with Hasura
description: Use Postgres custom functions with Hasura
keywords:
- hasura
- docs
@ -10,18 +10,18 @@ sidebar_position: 4
sidebar_label: Functions
---
# Postgres functions
# Postgres custom functions
## Introduction
[Postgres functions](https://www.postgresql.org/docs/current/sql-createfunction.html) allow you to customize your
[Postgres custom functions](https://www.postgresql.org/docs/current/sql-createfunction.html) allow you to customize your
database schema by defining a set of operations that can include several statements such as declarations, assignments
and conditional workflows. Postgres functions are similar to views but allow more procedural computations and can take
arguments. SQL functions are also referred to as **stored procedures**.
arguments. Custom SQL functions are also referred to as **stored procedures**.
:::info Note
For more information on Postgres functions, please refer to the
For more information on Postgres custom functions, please refer to the
[Postgres documentation](https://www.postgresql.org/docs/current/sql-createfunction.html).
:::
@ -52,11 +52,11 @@ Let's break this function apart:
- Function body: Block from `SELECT` until the end of the `WHERE` clause
- Language: The response is returned in the `sql` language
## Postgres functions & Hasura
## Postgres custom functions & Hasura
Postgres functions can be exposed in Hasura's GraphQL schema as a top-level field or as a computed field for a table.
Postgres custom functions can be exposed in Hasura's GraphQL schema as a top-level field or as a computed field for a table.
They are typically used for performing custom business logic in the database.
Refer to [Custom SQL functions](/schema/postgres/custom-functions.mdx) and
[Computed fields](/schema/postgres/computed-fields.mdx) for more use cases and for instructions on how to create and
expose Postgres functions in Hasura.
expose Postgres custom functions in Hasura.

View File

@ -49,7 +49,7 @@ data and extend your Hasura GraphQL API:
- [Constraints](/guides/postgres/constraints.mdx)
- [Views](/guides/postgres/views.mdx)
- [Functions](/guides/postgres/functions.mdx)
- [Custom Functions](/guides/postgres/functions.mdx)
- [Triggers](/guides/postgres/triggers.mdx)
- [Indexes](/guides/postgres/indexes.mdx)
- [Import data from CSV](/guides/postgres/import-data-from-csv.mdx)

View File

@ -25,7 +25,7 @@ remote_schemas: []
tables: []
```
Depending on the tables tracked, remote schemas and functions created,
Depending on the tables tracked, remote schemas and custom functions created,
these keys will have elements inside them.
The `table` will have permission rules, relationships and event triggers

View File

@ -19,7 +19,7 @@ import Thumbnail from '@site/src/components/Thumbnail';
If your Postgres schema is already managed with a tool like knex, TypeORM, Django/Rails migrations, you will still need
a way to export the actions you performed on the Hasura console to apply it later on another Hasura instance.
All the actions performed on the console, like tracking tables/views/functions, creating relationships, configuring
All the actions performed on the console, like tracking tables/views/custom functions, creating relationships, configuring
permissions, creating event triggers and remote schemas, etc. can be exported as a JSON/yaml metadata file which can be
version controlled. The metadata file can be later imported to another Hasura instance to get the same configuration.
You can also manually edit the metadata file to add more objects to it and then use it to update the instance.

View File

@ -22,7 +22,7 @@ Let's first talk about metadata. Whenever you do certain actions on the
console or via the API, Hasura records it in the [metadata catalogue](/migrations-metadata-seeds/legacy-configs/config-v2/reference/metadata-format.mdx)
which is a schema called `hdb_catalog` in your Postgres database. For example, if you track a table, a new entry is
created in the `hdb_catalog.hdb_table` table in Postgres. Similarly, there are more tables in this schema to track
relationships, event triggers, functions and remote schemas.
relationships, event triggers, custom functions and remote schemas.
All information in this schema can be exported as files. Export options
are available on the console, CLI and via the API. These files when

View File

@ -124,7 +124,7 @@ This file specifies the metadata related to a table called `tracks` in
it's metadata specifically. This makes understanding and managing
metadata related to tables a lot easier.
Also note that Metadata related to functions is also managed in a
Also note that Metadata related to custom functions is also managed in a
similar fashion.
When doing a `hasura metadata apply` CLI will inline `!include`

View File

@ -16,7 +16,7 @@ import Thumbnail from '@site/src/components/Thumbnail';
## Introduction
We call the Hasura Server configuration the Metadata. All changes made to the Hasura instance via the Console or via the
API such as tracking tables / views / functions, creating relationships, configuring permissions, creating event
API such as tracking tables / views / custom functions, creating relationships, configuring permissions, creating event
triggers and remote schemas, etc. are tracked by Hasura using the Metadata Catalogue and their state can be exported as
YAML or JSON Metadata files.
@ -215,7 +215,7 @@ is set, add `-H 'X-Hasura-Admin-Secret: [your-admin-secret]'` as the API is an a
:::info Note
All the dependent objects, like tables, views, functions etc. should exist on the database before importing the
All the dependent objects, like tables, views, custom functions etc. should exist on the database before importing the
Metadata. Otherwise, it will result in an error saying the object does not exist. So,
[apply the database Migration](/migrations-metadata-seeds/manage-migrations.mdx#apply-migrations) schema first, before
apply the Metadata.