upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-04-14 05:27:20 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/interfaces/ecpg
History
Peter Eisentraut e4128ee767 SQL procedures 
This adds a new object type "procedure" that is similar to a function
but does not have a return type and is invoked by the new CALL statement
instead of SELECT or similar.  This implementation is aligned with the
SQL standard and compatible with or similar to other SQL implementations.

This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well
as ALTER/DROP ROUTINE that can refer to either a function or a
procedure (or an aggregate function, as an extension to SQL).  There is
also support for procedures in various utility commands such as COMMENT
and GRANT, as well as support in pg_dump and psql.  Support for defining
procedures is available in all the languages supplied by the core
distribution.

While this commit is mainly syntax sugar around existing functionality,
future features will rely on having procedures as a separate object
type.

Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-11-30 11:03:20 -05:00
..
compatlib Add some const decorations to prototypes 2017-11-10 13:38:57 -05:00
ecpglib Update typedefs.list and re-run pgindent 2017-11-29 09:24:24 -05:00
include Add some const decorations to prototypes 2017-11-10 13:38:57 -05:00
pgtypeslib Add some const decorations to prototypes 2017-11-10 13:38:57 -05:00
preproc SQL procedures 2017-11-30 11:03:20 -05:00
test Add post-2010 ecpg tests to checktcp. 2017-11-11 14:35:22 -08:00
Makefile Fix parallel make risk with new check temp-install setup 2015-04-29 20:34:22 -04:00
README.dynSQL Fix whitespace issues found by git diff --check, add gitattributes 2013-11-10 14:48:29 -05:00

README.dynSQL 

src/interfaces/ecpg/README.dynSQL

descriptor statements have the following shortcomings

- input descriptors (USING DESCRIPTOR <name>) are not supported

  Reason: to fully support dynamic SQL the frontend/backend communication
          should change to recognize input parameters.
          Since this is not likely to happen in the near future and you
          can cover the same functionality with the existing infrastructure
          (using s[n]printf), I'll leave the work to someone else.