Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
5e84d58e
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,发现更多精彩内容 >>
提交
5e84d58e
编写于
6月 14, 1999
作者:
T
Thomas G. Lockhart
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Minor updates for release.
上级
abc40591
变更
5
展开全部
隐藏空白更改
内联
并排
Showing
5 changed file
with
851 addition
and
819 deletion
+851
-819
doc/src/sgml/datatype.sgml
doc/src/sgml/datatype.sgml
+1
-1
doc/src/sgml/docguide.sgml
doc/src/sgml/docguide.sgml
+5
-2
doc/src/sgml/func.sgml
doc/src/sgml/func.sgml
+682
-680
doc/src/sgml/lobj.sgml
doc/src/sgml/lobj.sgml
+155
-130
doc/src/sgml/release.sgml
doc/src/sgml/release.sgml
+8
-6
未找到文件。
doc/src/sgml/datatype.sgml
浏览文件 @
5e84d58e
<chapter id="datatype">
<title>Data Types</title>
<title
id="datatype-title"
>Data Types</title>
<abstract>
<para>
...
...
doc/src/sgml/docguide.sgml
浏览文件 @
5e84d58e
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.1
5 1999/05/27 15:49:07
thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.1
6 1999/06/14 07:36:11
thomas Exp $
Documentation Guide
Thomas Lockhart
$Log: docguide.sgml,v $
Revision 1.16 1999/06/14 07:36:11 thomas
Minor updates for release.
Revision 1.15 1999/05/27 15:49:07 thomas
Markup fixes.
Update for v6.5 release.
...
...
@@ -175,7 +178,7 @@ Include working list of all documentation sources, with current status
James Clark's
<ulink url="http://www.jclark.com/jade/"> <productname>jade</productname></ulink>
and Norm Walsh's
<ulink url="http://www.
berkshire.net/~norm/docbook/dsssl
">Modular DocBook Stylesheets</ulink>.
<ulink url="http://www.
nwalsh.com/docbook/dsssl/
">Modular DocBook Stylesheets</ulink>.
</para>
<para>
...
...
doc/src/sgml/func.sgml
浏览文件 @
5e84d58e
此差异已折叠。
点击以展开。
doc/src/sgml/lobj.sgml
浏览文件 @
5e84d58e
<Chapter Id="largeObjects">
<Title>Large Objects</Title>
<Para>
In <ProductName>Postgres</ProductName>, data values are stored in tuples and
individual tuples cannot span data pages. Since the size of
a data page is 8192 bytes, the upper limit on the size
of a data value is relatively low. To support the storage
of larger atomic values, <ProductName>Postgres</ProductName> provides a large
object interface. This interface provides file
oriented access to user data that has been declared to
be a large type.
This section describes the implementation and the
programmatic and query language interfaces to <ProductName>Postgres</ProductName>
large object data.
</Para>
<Sect1>
<Title>Historical Note</Title>
<Para>
Originally, <ProductName>Postgres 4.2</ProductName> supported three standard
<chapter id="largeObjects">
<title id="largeObjects-title">Large Objects</title>
<para>
In <productname>Postgres</productname>,
data values are stored in tuples and
individual tuples cannot span data pages. Since the size of
a data page is 8192 bytes, the upper limit on the size
of a data value is relatively low. To support the storage
of larger atomic values,
<productname>Postgres</productname> provides a large
object interface. This interface provides file
oriented access to user data that has been declared to
be a large type.
This section describes the implementation and the
programmatic and query language interfaces to
<productname>Postgres</productname>
large object data.
</para>
<sect1>
<title>Historical Note</title>
<para>
Originally, <productname>Postgres 4.2</productname> supported three standard
implementations of large objects: as files external
to <ProductName>Postgres</ProductName>, as <Acronym>UNIX</Acronym> files managed by <ProductName>Postgres</ProductName>, and as data
stored within the <ProductName>Postgres</ProductName> database. It causes
to <productname>Postgres</productname>, as
<acronym>ym>U</acronym>ym> files managed by <productname>Postgres</productname>, and as data
stored within the <productname>Postgres</productname> database. It causes
considerable confusion among users. As a result, we only
support large objects as data stored within the <
ProductName>Postgres</ProductN
ame>
database in <
ProductName>PostgreSQL</ProductN
ame>. Even though it is slower to
support large objects as data stored within the <
productname>Postgres</productn
ame>
database in <
productname>PostgreSQL</productn
ame>. Even though it is slower to
access, it provides stricter data integrity.
For historical reasons, this storage scheme is referred to as
Inversion large objects. (We will use Inversion and large
objects interchangeably to mean the same thing in this
section.)
</
P
ara>
</
S
ect1>
</
p
ara>
</
s
ect1>
<
S
ect1>
<
Title>Inversion Large Objects</T
itle>
<
s
ect1>
<
title>Inversion Large Objects</t
itle>
<
P
ara>
<
p
ara>
The Inversion large object implementation breaks large
objects up into "chunks" and stores the chunks in
tuples in the database. A B-tree index guarantees fast
searches for the correct chunk number when doing random
access reads and writes.
</
P
ara>
</
S
ect1>
</
p
ara>
</
s
ect1>
<
S
ect1>
<
Title>Large Object Interfaces</T
itle>
<
s
ect1>
<
title>Large Object Interfaces</t
itle>
<
P
ara>
The facilities <
ProductName>Postgres</ProductN
ame> provides to access large
<
p
ara>
The facilities <
productname>Postgres</productn
ame> provides to access large
objects, both in the backend as part of user-defined
functions or the front end as part of an application
using the interface, are described below. (For users
familiar with <ProductName>Postgres 4.2</ProductName>, <ProductName>PostgreSQL</ProductName> has a new set of
familiar with <productname>Postgres 4.2</productname>,
<productname>PostgreSQL</productname> has a new set of
functions providing a more coherent interface. The
interface is the same for dynamically-loaded C
functions as well as for XXX LOST TEXT? WHAT SHOULD GO HERE??.
The <ProductName>Postgres</ProductName> large object interface is modeled after
the <Acronym>UNIX</Acronym> file system interface, with analogues of
<Function>open(2)</Function>, <Function>read(2)</Function>, <Function>write(2)</Function>,
<Function>lseek(2)</Function>, etc. User
The <productname>Postgres</productname> large object interface is modeled after
the <acronym>UNIX</acronym> file system interface, with analogues of
<function>open(2)</function>, <function>read(2)</function>,
<function>write(2)</function>,
<function>lseek(2)</function>, etc. User
functions call these routines to retrieve only the data of
interest from a large object. For example, if a large
object type called mugshot existed that stored
...
...
@@ -72,81 +78,82 @@
the beard that appeared there, if any. The entire
large object value need not be buffered, or even
examined, by the beard function.
Large objects may be accessed from dynamically-loaded <
Acronym>C</A
cronym>
Large objects may be accessed from dynamically-loaded <
acronym>C</a
cronym>
functions or database client programs that link the
library. <
ProductName>Postgres</ProductN
ame> provides a set of routines that
library. <
productname>Postgres</productn
ame> provides a set of routines that
support opening, reading, writing, closing, and seeking on
large objects.
</
P
ara>
</
p
ara>
<
S
ect2>
<
Title>Creating a Large Object</T
itle>
<
s
ect2>
<
title>Creating a Large Object</t
itle>
<
P
ara>
<
p
ara>
The routine
<
ProgramL
isting>
<
programl
isting>
Oid lo_creat(PGconn *conn, int mode)
</
ProgramL
isting>
</
programl
isting>
creates a new large object. The mode is a bitmask
describing several different attributes of the new
object. The symbolic constants listed here are defined
in
<
FileN
ame>
<
filen
ame>
PGROOT/src/backend/libpq/libpq-fs.h
</
FileN
ame>
</
filen
ame>
The access type (read, write, or both) is controlled by
OR ing together the bits <Acronym>INV_READ</Acronym> and <Acronym>INV_WRITE</Acronym>. If
OR ing together the bits <acronym>INV_READ</acronym> and
<acronym>INV_WRITE</acronym>. If
the large object should be archived -- that is, if
historical versions of it should be moved periodically to
a special archive relation -- then the <
Acronym>INV_ARCHIVE</A
cronym> bit
a special archive relation -- then the <
acronym>INV_ARCHIVE</a
cronym> bit
should be set. The low-order sixteen bits of mask are
the storage manager number on which the large object
should reside. For sites other than Berkeley, these
bits should always be zero.
The commands below create an (Inversion) large object:
<
ProgramL
isting>
<
programl
isting>
inv_oid = lo_creat(INV_READ|INV_WRITE|INV_ARCHIVE);
</
ProgramL
isting>
</
P
ara>
</
S
ect2>
</
programl
isting>
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Importing a Large Object</T
itle>
<
s
ect2>
<
title>Importing a Large Object</t
itle>
<
P
ara>
To import a <
Acronym>UNIX</A
cronym> file as
<
p
ara>
To import a <
acronym>UNIX</a
cronym> file as
a large object, call
<
ProgramL
isting>
<
programl
isting>
Oid lo_import(PGconn *conn, text *filename)
</
ProgramL
isting>
The filename argument specifies the <
Acronym>UNIX</A
cronym> pathname of
</
programl
isting>
The filename argument specifies the <
acronym>UNIX</a
cronym> pathname of
the file to be imported as a large object.
</
P
ara>
</
S
ect2>
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Exporting a Large Object</T
itle>
<
s
ect2>
<
title>Exporting a Large Object</t
itle>
<
P
ara>
<
p
ara>
To export a large object
into <
Acronym>UNIX</A
cronym> file, call
<
ProgramL
isting>
into <
acronym>UNIX</a
cronym> file, call
<
programl
isting>
int lo_export(PGconn *conn, Oid lobjId, text *filename)
</
ProgramL
isting>
</
programl
isting>
The lobjId argument specifies the Oid of the large
object to export and the filename argument specifies
the <
Acronym>UNIX</A
cronym> pathname of the file.
</
P
ara>
</
S
ect2>
the <
acronym>UNIX</a
cronym> pathname of the file.
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Opening an Existing Large Object</T
itle>
<
s
ect2>
<
title>Opening an Existing Large Object</t
itle>
<
P
ara>
<
p
ara>
To open an existing large object, call
<
ProgramL
isting>
<
programl
isting>
int lo_open(PGconn *conn, Oid lobjId, int mode, ...)
</
ProgramL
isting>
</
programl
isting>
The lobjId argument specifies the Oid of the large
object to open. The mode bits control whether the
object is opened for reading INV_READ), writing or
...
...
@@ -154,64 +161,65 @@ int lo_open(PGconn *conn, Oid lobjId, int mode, ...)
A large object cannot be opened before it is created.
lo_open returns a large object descriptor for later use
in lo_read, lo_write, lo_lseek, lo_tell, and lo_close.
</
P
ara>
</
S
ect2>
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Writing Data to a Large Object</T
itle>
<
s
ect2>
<
title>Writing Data to a Large Object</t
itle>
<
P
ara>
<
p
ara>
The routine
<
ProgramL
isting>
<
programl
isting>
int lo_write(PGconn *conn, int fd, char *buf, int len)
</
ProgramL
isting>
</
programl
isting>
writes len bytes from buf to large object fd. The fd
argument must have been returned by a previous lo_open.
The number of bytes actually written is returned. In
the event of an error, the return value is negative.
</
P
ara>
</
S
ect2>
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Seeking on a Large Object</T
itle>
<
s
ect2>
<
title>Seeking on a Large Object</t
itle>
<
P
ara>
<
p
ara>
To change the current read or write location on a large
object, call
<
ProgramL
isting>
<
programl
isting>
int lo_lseek(PGconn *conn, int fd, int offset, int whence)
</
ProgramL
isting>
</
programl
isting>
This routine moves the current location pointer for the
large object described by fd to the new location specified
by offset. The valid values for .i whence are
SEEK_SET SEEK_CUR and SEEK_END.
</
P
ara>
</
S
ect2>
</
p
ara>
</
s
ect2>
<
S
ect2>
<
Title>Closing a Large Object Descriptor</T
itle>
<
s
ect2>
<
title>Closing a Large Object Descriptor</t
itle>
<
P
ara>
<
p
ara>
A large object may be closed by calling
<
ProgramL
isting>
<
programl
isting>
int lo_close(PGconn *conn, int fd)
</
ProgramL
isting>
</
programl
isting>
where fd is a large object descriptor returned by
lo_open. On success, <
Acronym>lo_close</A
cronym> returns zero. On error,
lo_open. On success, <
acronym>lo_close</a
cronym> returns zero. On error,
the return value is negative.
</
P
ara>
</
p
ara>
</sect2>
</
S
ect1>
</
s
ect1>
<
S
ect1>
<
Title>Built in registered functions</T
itle>
<
s
ect1>
<
title>Built in registered functions</t
itle>
<Para>
There are two built-in registered functions, <Acronym>lo_import</Acronym>
and <Acronym>lo_export</Acronym> which are convenient for use in <Acronym>SQL</Acronym>
<para>
There are two built-in registered functions, <acronym>lo_import</acronym>
and <acronym>lo_export</acronym> which are convenient for use
in <acronym>SQL</acronym>
queries.
Here is an example of their use
<
ProgramL
isting>
<
programl
isting>
CREATE TABLE image (
name text,
raster oid
...
...
@@ -222,33 +230,33 @@ INSERT INTO image (name, raster)
SELECT lo_export(image.raster, "/tmp/motd") from image
WHERE name = 'beautiful image';
</
ProgramL
isting>
</
P
ara>
</
S
ect1>
</
programl
isting>
</
p
ara>
</
s
ect1>
<
S
ect1>
<
Title>Accessing Large Objects from LIBPQ</T
itle>
<
s
ect1>
<
title>Accessing Large Objects from LIBPQ</t
itle>
<
P
ara>
<
p
ara>
Below is a sample program which shows how the large object
interface
in LIBPQ can be used. Parts of the program are
commented out but are left in the source for the readers
benefit. This program can be found in
<
FileN
ame>
<
filen
ame>
../src/test/examples
</
FileN
ame>
</
filen
ame>
Frontend applications which use the large object interface
in LIBPQ should include the header file
libpq/libpq-fs.h and link with the libpq library.
</
P
ara>
</
S
ect1>
</
p
ara>
</
s
ect1>
<
S
ect1>
<
Title>Sample Program</T
itle>
<
s
ect1>
<
title>Sample Program</t
itle>
<
P
ara>
<
ProgramL
isting>
<
p
ara>
<
programl
isting>
/*--------------------------------------------------------------
*
* testlo.c--
...
...
@@ -479,8 +487,25 @@ SELECT lo_export(image.raster, "/tmp/motd") from image
PQfinish(conn);
exit(0);
}
</ProgramListing>
</Para>
</Sect1>
</Chapter>
</programlisting>
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
doc/src/sgml/release.sgml
浏览文件 @
5e84d58e
...
...
@@ -23,7 +23,7 @@
</para>
<para>
Here is a brief summary of
some of the more notic
able changes:
Here is a brief summary of
the more not
able changes:
<variablelist>
<varlistentry>
...
...
@@ -188,16 +188,16 @@
<para>
Because readers in 6.5 don't lock data, regardless of transaction
isolation level, data read by one transaction can be overwritten by
another. In
the
other words, if a row is returned by
another. In other words, if a row is returned by
<command>SELECT</command> it doesn't mean that this row really exists
at the time it is returned (i.e. sometime after the statement or
transaction began) nor that the row is protected from
deletion
or
update by concurrent transactions before the current transaction does
transaction began) nor that the row is protected from
being deleted
or
update
d
by concurrent transactions before the current transaction does
a commit or rollback.
</para>
<para>
To ensure the actual exist
a
nce of a row and protect it against
To ensure the actual exist
e
nce of a row and protect it against
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
an appropriate <command>LOCK TABLE</command> statement. This should be
taken into account when porting applications from previous releases of
...
...
@@ -205,7 +205,8 @@
</para>
<para>
Keep above in mind if you are using contrib/refint.* triggers for
Keep the above in mind if you are using
<filename>contrib/refint.*</filename> triggers for
referential integrity. Additional technics are required now. One way is
to use <command>LOCK parent_table IN SHARE ROW EXCLUSIVE MODE</command>
command if a transaction is going to update/delete a primary key and
...
...
@@ -2634,6 +2635,7 @@ Initial release.
<programlisting>
Time System
02:00 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
04:38 Sparc Ultra 1 143MHz, 64MB, Solaris 2.6
</programlisting>
</para>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录