Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
48c91649
Commit
48c91649
authored
Mar 22, 2002
by
Tom Lane
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Improve catalog commentary.
parent
b6ea172a
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
42 additions
and
24 deletions
+42
-24
src/backend/catalog/README
src/backend/catalog/README
+42
-24
No files found.
src/backend/catalog/README
View file @
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
This directory contains .c files that manipulate the system catalogs
as well as .h files that define the structure of 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
...
@@ -23,34 +23,52 @@ bootstrap/ directory. Just be careful when adding new DATA
statements.
statements.
- Some catalogs require that OIDs be preallocated to tuples because
- Some catalogs require that OIDs be preallocated to tuples because
certain catalogs contain circular referenc
es. For example, pg_type
of cross-references from other pre-loaded tupl
es. For example, pg_type
contains pointers into pg_proc (pg_type.typinput), and pg_proc
contains pointers into pg_proc (
e.g.,
pg_type.typinput), and pg_proc
contains back-pointers into pg_type (pg_proc.proargtypes).
In these
contains back-pointers into pg_type (pg_proc.proargtypes).
For such
cases, the
references may be explicitly set by use of the "OID ="
cases, the
OID assigned to a tuple may be explicitly set by use of the
clause of the .bki insert statement. If no such pointers are required
"OID =" clause of the .bki insert statement. If no such pointers are
to a given tuple, then the OID may be set to the wildcard value 0
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
(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
- We also sometimes preallocate OIDs for catalog tuples whose OIDs must
other, use the unused_oids script. It generates inclusive ranges of
be known directly in the C code. In such cases, put a #define in the
*unused* OIDs (i.e., the line "45-900" means OIDs 45 through 900 have
catalog's .h file, and use the #define symbol in the C code. Writing
not been allocated yet). All OIDs that are known directly to C code
the actual numeric value of any OID in C code is considered very bad form.
should be referenced via #defines in the catalog .h files. So
(Direct references to pg_proc OIDs are common enough that there's a special
unused_oids is sufficient for assigning new OIDs.). The unused_oids
mechanism to create the necessary #define's automatically. For all the
script simply 'discovers' those which are free.
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
-
If you need to find a valid OID for a tuple that will be referred to by
variable, as these will not be created through standard function means, but
others, use the unused_oids script. It generates inclusive ranges of
will be written directly to disk. Thats how pg_class is created without
*unused* OIDs (i.e., the line "45-900" means OIDs 45 through 900 have
depending on functions which depend on the existance of pg_class. The
not been allocated yet). Currently, OIDs 1-9999 are reserved for manual
list of files this currently includes is:
assignment; the unused_oids script simply looks through the include/catalog
pg_proc.h pg_type.h pg_attribute.h pg_class.h
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
- To create a "BOOTSTRAP" table you have to do a lot of extra work: these
sets the OID of the relation when it's a bootstrapped system table. It's
tables are not created through a normal CREATE TABLE operation, but spring
near the top of the function with the comment beginning in 'Real ugly stuff'
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.
-----------------------------------------------------------------
-----------------------------------------------------------------
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment