Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
48c91649
Commit
48c91649
authored
23 years ago
by
Tom Lane
Browse files
Options
Downloads
Patches
Plain Diff
Improve catalog commentary.
parent
b6ea172a
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
src/backend/catalog/README
+42
-24
42 additions, 24 deletions
src/backend/catalog/README
with
42 additions
and
24 deletions
src/backend/catalog/README
+
42
−
24
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 circula
r re
ferenc
es. For example, pg_type
of cross-references from othe
r
p
re
-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
OID
s
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
reference
d via #defines in the catalog .h files. So
(Direct
reference
s 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
a
t
t
he start of the Makefile POSTGRES_BKI_SRCS
-
If you need to find a valid OID for
a t
uple 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_clas
s.
h
headers to see which ones do not appear in "OID =" clause
s.
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.
-----------------------------------------------------------------
-----------------------------------------------------------------
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment