Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
f9e497db
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
f9e497db
编写于
5月 20, 1999
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Doco updates for change to handling of INTERNAL function
entries (prosrc is now name of C-level function).
上级
77d33559
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
51 addition
and
27 deletion
+51
-27
src/man/catalogs.3
src/man/catalogs.3
+7
-3
src/man/create_function.l
src/man/create_function.l
+44
-24
未找到文件。
src/man/catalogs.3
浏览文件 @
f9e497db
.\" This is -*-nroff-*-
.\" XXX standard disclaimer belongs here....
.\" $Header: /cvsroot/pgsql/src/man/Attic/catalogs.3,v 1.
5 1998/03/25 01:54:49 momjian
Exp $
.\" $Header: /cvsroot/pgsql/src/man/Attic/catalogs.3,v 1.
6 1999/05/20 02:44:53 tgl
Exp $
.TH "SYSTEM CATALOGS" INTRO 03/13/94 PostgreSQL PostgreSQL
.SH "Section 7 - System Catalogs"
.de LS
...
...
@@ -316,8 +316,12 @@ pg_proc
size) */
int4 prooutin_ratio /* size of the function's output as a
percentage of the size of the input */
text prosrc /* function definition (postquel only) */
bytea probin /* path to object file (C only) */
text prosrc /* function definition:
INTERNAL function: actual C name of function
C function: currently, this field is unused
SQL function: text of query(s)
PL function: text in procedural language */
bytea probin /* path to object file (C functions only) */
.fi
.nf M
pg_language
...
...
src/man/create_function.l
浏览文件 @
f9e497db
.\" This is -*-nroff-*-
.\" XXX standard disclaimer belongs here....
.\" $Header: /cvsroot/pgsql/src/man/Attic/create_function.l,v 1.1
0 1998/06/24 13:21:24 momjian
Exp $
.\" $Header: /cvsroot/pgsql/src/man/Attic/create_function.l,v 1.1
1 1999/05/20 02:44:53 tgl
Exp $
.TH "CREATE FUNCTION" SQL 11/05/95 PostgreSQL PostgreSQL
.SH "NAME"
create function - define a new function
...
...
@@ -9,8 +9,9 @@ create function - define a new function
\fBcreate function\fP function_name
\fB(\fP[type1 {, type-n}]\fB)\fP
\fBreturns\fP type-r
\fBas\fP {'/full/path/to/objectfile' | 'sql-queries'}
\fBlanguage\fP {'c' \ 'sql' \ 'internal' \ 'plname'}
\fBas\fP { '/full/path/to/objectfile' | 'sql-queries' |
'builtin-function-name' | 'pl-program-text' }
\fBlanguage\fP { 'c' | 'sql' | 'internal' | 'plname' }
.fi
.SH "DESCRIPTION"
With this command, a Postgres user can register a function with Postgres.
...
...
@@ -35,9 +36,8 @@ or
.IR "plname"
is the language name of a created procedural language. See
create_language(l) for details.)
(The
.IR "arg is"
clause may be left out if the function has no arguments, or
(The argument list
may be left out if the function has no arguments, or
alternatively the argument list may be left empty.)
The input types may be base or complex types, or
.IR opaque .
...
...
@@ -54,32 +54,43 @@ modifier indicates that the function will return a set of items,
rather than a single item.
The
.IR as
clause of the command is treated differently for C and SQL
functions, as explained below.
clause of the command is treated differently depending on the language,
as explained below.
.SH "INTERNAL FUNCTIONS"
Internal functions are functions written in C which have been statically
linked into the postgres backend process. The
.BR as
clause gives the C-language name of the function, which need not be the
same as the name being declared for SQL use. (For reasons of backwards
compatibility, an empty
.BR as
string is accepted as meaning that the C-language function name is the
same as the SQL name.) Normally, all internal functions present in the
backend are declared as SQL functions during database initialization,
but a user could use
.BR "create function"
to create additional alias names for an internal function.
.SH "C FUNCTIONS"
Functions written in C can be defined to Postgres, which will dynamically
load them into its address space. The loading happens either using
load them into its address space. The
.IR as
clause gives the full path name of the object file that contains the
function. This file is loaded either using
.IR load(l)
or automatically the first time the function is necessary for
execution. Repeated execution of a function will cause negligible
additional overhead, as the function will remain in a main memory
cache.
.PP
Internal functions are functions written in C which have been statically
linked into the postgres backend process. The
.BR as
clause must still be specified when defining an internal function but
the contents are ignored.
.SH "Writing C Functions"
The body of a C function
following
For a C function, the string
following
.BR as
should be the
.BR "FULL PATH"
of the object code
(.o file)
for the function, bracketed by quotation
of the object code
file
for the function, bracketed by quotation
marks. (Postgres will not compile a function automatically - it must
be compiled before it is used in a
.BR "
defin
e function"
command.)
.BR "
creat
e function"
command.
See below for additional information.
)
.PP
C functions with base type arguments can be written in a
straightforward fashion. The C equivalents of built-in Postgres types
...
...
@@ -297,7 +308,7 @@ on. If an argument is complex, then a \*(lqdot\*(rq notation may be
used to access attributes of the argument (e.g. \*(lq$1.emp\*(rq), or
to invoke functions via a nested-dot syntax.
.SH "PL FUNCTIONS"
Procedural languages aren't built
in
to Postgres. They are offered
Procedural languages aren't built
in
to Postgres. They are offered
by loadable modules. Please refer to the documentation for the
PL in question for details about the syntax and how the
.IR "as"
...
...
@@ -400,10 +411,11 @@ A function may also have the same name as an attribute. In the case
that there is an ambiguity between a function on a complex type and
an attribute of the complex type, the attribute will always be used.
.SH "RESTRICTIONS"
The name of the C function must be a legal C function name, and the
name of the function in C code must be exactly the same as the name
used in
.BR "create function" .
For functions written in C, the SQL name declared in
.BR "create function"
must be exactly the same as the actual name of the function in the
C code (hence it must be a legal C function name).
.PP
There is a subtle implication of this restriction: while the
dynamic loading routines in most operating systems are more than
happy to allow you to load any number of shared libraries that
...
...
@@ -422,6 +434,14 @@ define a set of C functions with different names and then define
a set of identically-named SQL function wrappers that take the
appropriate argument types and call the matching C function.
.PP
Another solution is not to use dynamic loading, but to link your
functions into the backend statically and declare them as INTERNAL
functions. Then, the functions must all have distinct C names but
they can be declared with the same SQL names (as long as their
argument types differ, of course). This way avoids the overhead of
an SQL wrapper function, at the cost of more effort to prepare a
custom backend executable.
.PP
.IR opaque
cannot be given as an argument to a SQL function.
.SH "BUGS"
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录