database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-01 12:18:01 +03:00
Code Activity

Make source code READMEs more consistent. Add CVS tags to all README files.

Browse Source
This commit is contained in:
Bruce Momjian
2008-03-20 17:55:15 +00:00
parent 27dfc11d67
commit 4e228447aa
22 changed files with 148 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
src/backend/utils/fmgr/README
View File

@@ -1,4 +1,9 @@
Proposal for function-manager redesign 19-Nov-2000
$PostgreSQL: pgsql/src/backend/utils/fmgr/README,v 1.10 2008/03/20 17:55:15 momjian Exp $
Function Manager
================
Proposal For Function-Manager Redesign 19-Nov-2000
--------------------------------------
We know that the existing mechanism for calling Postgres functions needs
@@ -25,7 +30,7 @@ written in the old style can be left in place indefinitely, to provide
backward compatibility for user-written C functions.
Changes in pg_proc (system data about a function)
Changes In pg_proc (System Data About a Function)
-------------------------------------------------
A new column "proisstrict" will be added to the system pg_proc table.
@@ -45,7 +50,7 @@ more useful case for functions expressed in SQL or a PL language, but
am open to arguments for the other choice.
The new function-manager interface
The New Function-Manager Interface
----------------------------------
The core of the new design is revised data structures for representing
@@ -165,7 +170,7 @@ through a function pointer declared with exactly that signature, we
should have no portability or optimization problems.
Function coding conventions
Function Coding Conventions
---------------------------
As an example, int4 addition goes from old-style
@@ -277,7 +282,7 @@ fields of FunctionCallInfo, it should just do it. I doubt that providing
syntactic-sugar macros for these cases is useful.
Call-site coding conventions
Call-Site Coding Conventions
----------------------------
There are many places in the system that call either a specific function
@@ -339,7 +344,7 @@ have to change in the first step of implementation, but they can
continue to support the same external appearance.
Support for TOAST-able data types
Support for TOAST-Able Data Types
---------------------------------
For TOAST-able data types, the PG_GETARG macro will deliver a de-TOASTed
@@ -372,7 +377,7 @@ context. When and if the value is actually stored into a tuple, the
tuple toaster will decide whether toasting is needed.
Functions accepting or returning sets
Functions Accepting or Returning Sets
-------------------------------------
[ this section revised 29-Aug-2002 for 7.3 ]
@@ -436,7 +441,7 @@ There is no support for functions accepting sets; instead, the function will
be called multiple times, once for each element of the input set.
Notes about function handlers
Notes About Function Handlers
-----------------------------
Handlers for classes of functions should find life much easier and
@@ -458,7 +463,7 @@ in any case it is required to be a context at least as long-lived as the
FmgrInfo itself.
Telling the difference between old- and new-style functions
Telling the Difference Between Old- and New-Style Functions
-----------------------------------------------------------
During the conversion process, we carried two different pg_language

5
src/backend/utils/mb/README
View File

@@ -1,3 +1,8 @@
$PostgreSQL: pgsql/src/backend/utils/mb/README,v 1.6 2008/03/20 17:55:15 momjian Exp $
Encodings
---------
encnames.c: public functions for both the backend and the frontend.
conv.c: static functions and a public table for code conversion
wchar.c: mostly static functions and a public table for mb string and

15
src/backend/utils/misc/README
View File

@@ -1,7 +1,7 @@
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.9 2008/03/16 16:42:44 mha Exp $
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.10 2008/03/20 17:55:15 momjian Exp $
GUC IMPLEMENTATION NOTES
Guc Implementation Notes
========================
The GUC (Grand Unified Configuration) module implements configuration
variables of multiple types (currently boolean, enum, int, float, and string).
@@ -9,7 +9,8 @@ Variable settings can come from various places, with a priority ordering
determining which setting is used.
PER-VARIABLE HOOKS
Per-Variable Hooks
------------------
Each variable known to GUC can optionally have an assign_hook and/or
a show_hook to provide customized behavior. Assign hooks are used to
@@ -69,7 +70,8 @@ This hook allows variable-specific computation of the value displayed
by SHOW.
SAVING/RESTORING GUC VARIABLE VALUES
Saving/Restoring Guc Variable Values
------------------------------------
Prior values of configuration variables must be remembered in order to deal
with several special cases: RESET (a/k/a SET TO DEFAULT), rollback of SET
@@ -208,7 +210,8 @@ with doit = false so that the value is validated, but no derived state is
changed.
STRING MEMORY HANDLING
String Memory Handling
----------------------
String option values are allocated with strdup, not with the
pstrdup/palloc mechanisms. We would need to keep them in a permanent

24
src/backend/utils/mmgr/README
View File

@@ -1,7 +1,7 @@
$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.11 2007/05/29 04:19:35 neilc Exp $
$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.12 2008/03/20 17:55:15 momjian Exp $
Notes about memory allocation redesign
--------------------------------------
Notes About Memory Allocation Redesign
======================================
Up through version 7.0, Postgres had serious problems with memory leakage
during large queries that process a lot of pass-by-reference data. There
@@ -53,7 +53,7 @@ that can be reset or deleted at strategic times within a query, such as
after each tuple.
Some notes about the palloc API versus standard C library
Some Notes About the palloc API Versus Standard C Library
---------------------------------------------------------
The behavior of palloc and friends is similar to the standard C library's
@@ -73,7 +73,7 @@ Similarly, repalloc allows realloc'ing to zero size.
* pfree and repalloc do not accept a NULL pointer. This is intentional.
pfree/repalloc no longer depend on CurrentMemoryContext
pfree/repalloc No Longer Depend On CurrentMemoryContext
-------------------------------------------------------
In this proposal, pfree() and repalloc() can be applied to any chunk
@@ -101,7 +101,7 @@ do". So there'd still need to be a global variable specifying a suitable
temporary-allocation context. That might as well be CurrentMemoryContext.
Additions to the memory-context mechanism
Additions to the Memory-Context Mechanism
-----------------------------------------
If we are going to have more contexts, we need more mechanism for keeping
@@ -130,7 +130,7 @@ children of a given context, but don't reset or delete that context
itself".
Globally known contexts
Globally Known Contexts
-----------------------
There will be several widely-known contexts that will typically be
@@ -214,7 +214,7 @@ if the backend has run out of memory otherwise. This allows out-of-memory
to be treated as a normal ERROR condition, not a FATAL error.
Contexts for prepared statements and portals
Contexts For Prepared Statements And Portals
--------------------------------------------
A prepared-statement object has an associated private context, in which
@@ -230,7 +230,7 @@ from prepared statements simply reference the prepared statements' trees,
and won't actually need any storage allocated in their private contexts.
Transient contexts during execution
Transient Contexts During Execution
-----------------------------------
When creating a prepared statement, the parse and plan trees will be built
@@ -318,7 +318,7 @@ processing. (Eventually we might have an even better solution from
nested transactions, but this'll do fine for now.)
Mechanisms to allow multiple types of contexts
Mechanisms to Allow Multiple Types of Contexts
----------------------------------------------
We may want several different types of memory contexts with different
@@ -389,7 +389,7 @@ compared to the existing code, so I think we're doing fine without
squeezing out that last little bit ...
More control over aset.c behavior
More Control Over aset.c Behavior
---------------------------------
Currently, aset.c allocates an 8K block upon the first allocation in
@@ -417,7 +417,7 @@ back to malloc() during reset, but just cleared. This avoids malloc
thrashing.
Other notes
Other Notes
-----------
The original version of this proposal suggested that functions returning

6
src/backend/utils/resowner/README
View File

@@ -1,6 +1,6 @@
$PostgreSQL: pgsql/src/backend/utils/resowner/README,v 1.5 2007/03/13 00:33:42 tgl Exp $
$PostgreSQL: pgsql/src/backend/utils/resowner/README,v 1.6 2008/03/20 17:55:15 momjian Exp $
Notes about resource owners
Notes About Resource Owners
---------------------------
ResourceOwner objects are a concept invented to simplify management of
@@ -39,7 +39,7 @@ because transactions may initiate operations that require resources (such
as query parsing) when no associated Portal exists yet.
API overview
API Overview
------------
The basic operations on a ResourceOwner are: