Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
48c91649
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,发现更多精彩内容 >>
提交
48c91649
编写于
3月 22, 2002
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Improve catalog commentary.
上级
b6ea172a
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
42 addition
and
24 deletion
+42
-24
src/backend/catalog/README
src/backend/catalog/README
+42
-24
未找到文件。
src/backend/catalog/README
浏览文件 @
48c91649
$Header: /cvsroot/pgsql/src/backend/catalog/README,v 1.
3 2002/03/19 01:14:41 momjian
Exp $
$Header: /cvsroot/pgsql/src/backend/catalog/README,v 1.
4 2002/03/22 20:14:42 tgl
Exp $
This directory contains .c files that manipulate the system catalogs
as well as .h files that define the structure of the system catalogs.
...
...
@@ -23,34 +23,52 @@ bootstrap/ directory. Just be careful when adding new DATA
statements.
- Some catalogs require that OIDs be preallocated to tuples because
certain catalogs contain circular referenc
es. For example, pg_type
contains pointers into pg_proc (pg_type.typinput), and pg_proc
contains back-pointers into pg_type (pg_proc.proargtypes).
In these
cases, the
references may be explicitly set by use of the "OID ="
clause of the .bki insert statement. If no such pointers are required
to a given tuple, then the OID may be set to the wildcard value 0
of cross-references from other pre-loaded tupl
es. For example, pg_type
contains pointers into pg_proc (
e.g.,
pg_type.typinput), and pg_proc
contains back-pointers into pg_type (pg_proc.proargtypes).
For such
cases, the
OID assigned to a tuple may be explicitly set by use of the
"OID =" clause of the .bki insert statement. If no such pointers are
required
to a given tuple, then the OID may be set to the wildcard value 0
(i.e., the system generates a random OID in the usual way, or leaves it
0 in a catalog that has no OIDs).
0 in a catalog that has no OIDs). In practice we usually preassign OIDs
for all or none of the pre-loaded tuples in a given catalog, even if only
some of them are actually cross-referenced.
If you need to find a valid OID for a set of tuples that refer to each
other, use the unused_oids script. It generates inclusive ranges of
*unused* OIDs (i.e., the line "45-900" means OIDs 45 through 900 have
not been allocated yet). All OIDs that are known directly to C code
should be referenced via #defines in the catalog .h files. So
unused_oids is sufficient for assigning new OIDs.). The unused_oids
script simply 'discovers' those which are free.
- We also sometimes preallocate OIDs for catalog tuples whose OIDs must
be known directly in the C code. In such cases, put a #define in the
catalog's .h file, and use the #define symbol in the C code. Writing
the actual numeric value of any OID in C code is considered very bad form.
(Direct references to pg_proc OIDs are common enough that there's a special
mechanism to create the necessary #define's automatically. For all the
other system catalogs, you have to manually create any #define's you need.)
-
BOOTSTRAP tables must be at the start of the Makefile POSTGRES_BKI_SRCS
variable, as these will not be created through standard function means, but
will be written directly to disk. Thats how pg_class is created without
depending on functions which depend on the existance of pg_class. The
list of files this currently includes is:
pg_proc.h pg_type.h pg_attribute.h pg_class.h
-
If you need to find a valid OID for a tuple that will be referred to by
others, use the unused_oids script. It generates inclusive ranges of
*unused* OIDs (i.e., the line "45-900" means OIDs 45 through 900 have
not been allocated yet). Currently, OIDs 1-9999 are reserved for manual
assignment; the unused_oids script simply looks through the include/catalog
headers to see which ones do not appear in "OID =" clauses.
Don't forget to add the entry to heap.c to function heap_create() which
sets the OID of the relation when it's a bootstrapped system table. It's
near the top of the function with the comment beginning in 'Real ugly stuff'
- To create a "BOOTSTRAP" table you have to do a lot of extra work: these
tables are not created through a normal CREATE TABLE operation, but spring
into existence when first written to during initdb. Therefore, you must
manually create appropriate entries for them in the pre-loaded contents of
pg_class, pg_attribute, and pg_type. You'll also need to add code to function
heap_create() in heap.c to force the correct OID to be assigned when the table
is first referenced. (It's near the top of the function with the comment
beginning in 'Real ugly stuff'.) Avoid making new catalogs be bootstrap
catalogs if at all possible; generally, only tables that must be written to
to create a table should be bootstrapped.
- Certain BOOTSTRAP tables must be at the start of the Makefile
POSTGRES_BKI_SRCS variable, as these will not be created through standard
function means, but will be written directly to disk. That's how pg_class is
created without depending on functions which depend on the existence of
pg_class. The list of files this currently includes is:
pg_proc.h pg_type.h pg_attribute.h pg_class.h
Also, indexing.h must be last, since the indexes can't be created until all
the tables are in place. There are reputedly some other order dependencies
in the .bki list, too.
-----------------------------------------------------------------
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录