I understand the distinction between:
- Scalar functions
- Set-Returning-Functions (SRF)s
- Internal functions
- Window functions
- Aggregate functions of all sorts
- User-Implemented functions (which in PostgreSQL can be implement in any language)
In SQL Server “Stored Procedures” are permitted through
EXEC. What does that provide over any other function executed with
SELECT that returns
When PostgreSQL gets Stored Procedures what will they bring me, and what is the formal distinction if any between a function and a stored procedure in the spec?
I read this question but it seems to predate the announcement of the implementation
Since Postgres functions (
CREATE FUNCTION) only run in a (single) transaction context, several important commands cannot be executed inside a function body. Like
CREATE DATABASE or
CREATE INDEX CONCURRENTLY or
VACUUM. The manual:
VACUUMcannot be executed inside a transaction block.
Functions are often called “stored procedures”, which has always been a misleading term – probably carried over from other RDBMS. With the arrival of SQL procedures (
CREATE PROCEDURE) in Postgres 11 that misnomer should be avoided completely.
SQL procedures can begin and end transactions. But the commands mentioned above are not allowed inside any transaction block at all, so those cannot be included in SQL procedures, either (yet).
Multiple result sets are planned for the future, but not implemented, yet.
PostgreSQL functions cannot start or end transactions. They are stuck with whatever transaction they inherited from their invoking query.
When PostgreSQL gets stored procedures, they will be able to open and close transactions.