opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity

bring it all into -current again

This commit is contained in:
Marc G. Fournier 1999-09-20 22:30:47 +00:00
parent 25acbc510b
commit a00a1a5641
93 changed files with 3460 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/bin/pgaccess/lib/help/abort.hlp Normal file
View File

@ -0,0 +1,10 @@
.pgaw:Help.f.t insert end \
"ABORT" {bold} " rolls back the current transaction and causes all the updates made by the transaction to be discarded. This command is identical in behavior to the SQL92 command ROLLBACK, and is present only for historical reasons.
" {} "Synopsis" {bold} "
" {} "ABORT" {code} "
" {} "Compatibility SQL92" {bold} "
This command is a Postgres extension present for historical reasons. " {} "ROLLBACK" {bold} " is the SQL92 equivalent command."

7
src/bin/pgaccess/lib/help/add_records.hlp Normal file
View File

@ -0,0 +1,7 @@
.pgaw:Help.f.t insert end \
"Adding new records to an existing table" {bold} "
" {} "Open a table for viewing and editing" {link open_table} " and move to the end of the displayed records using the vertical scrollbar. You will find there a single row containing only * characters. Click with the mouse on a field and start edit the new record. Move through the fields using Tab and Shift-Tab.
The new record will be saved into the database when you will select another record (or press on the mouse right-button).
"

30
src/bin/pgaccess/lib/help/alter_table.hlp Normal file
View File

@ -0,0 +1,30 @@
.pgaw:Help.f.t insert end "ALTER TABLE" {bold} " changes the definition of an existing table. The new columns and their types are specified in the same style and with the the same restrictions as in CREATE TABLE. The RENAME clause causes the name of a table or column to change without changing any of the data contained in the affected table. Thus, the table or column will remain of the same type and size after this command is executed.
" {} "Synopsis" {bold} "
ALTER TABLE table \[ * \] ADD \[ COLUMN \] column type
ALTER TABLE table \[ * \] RENAME \[ COLUMN \] column TO newcolumn
ALTER TABLE table RENAME TO newtable
" {code} "table" {italic} "
The name of an existing table to alter.
" {} "column" {italic} "
Name of a new or existing column.
" {} "type " {italic} "
Type of the new column.
" {} "newcolumn " {italic} "
New name for an existing column.
" {} "newtable " {italic} "
New name for an existing column.
You must own the table in order to change its schema.
" {} "Notes:" {italic} " The keyword COLUMN is noise and can be omitted.
\"\[*\]\" following a name of a table indicates that statement should be run over that table and all tables below it in the inheritance hierarchy. The PostgreSQL User's Guide has further information on inheritance.
Refer to " {} "CREATE TABLE" {link create_table} " for a further description of valid arguments."

49
src/bin/pgaccess/lib/help/alter_user.hlp Normal file
View File

@ -0,0 +1,49 @@
.pgaw:Help.f.t insert end "ALTER USER" {bold} " is used to change the attributes of a user's Postgres account. Please note that \
it is not possible to alter a user's " {} "usesysid" {bold} " via the alter user statement. Also, it is only possible for \
the Postgres user or any user with read and modify permissions on " {} "pg_shadow" {bold} " to alter user passwords. \
If any of the clauses of the alter user statement are omitted, the corresponding value in the " {} "pg_shadow" {bold} " table is left unchanged. \
" {} "Synopsis" {bold} "
ALTER USER username
\[ WITH PASSWORD password \]
\[ CREATEDB | NOCREATEDB \]
\[ CREATEUSER | NOCREATEUSER \]
\[ IN GROUP groupname \[, ...\] \]
\[ VALID UNTIL 'abstime' \]
" {code} "Inputs" {bold} "
Refer to CREATE USER for a detailed description of each clause.
" {} "username" {italic} "
The Postgres account name of the user whose details are to be altered.
" {} "password" {italic} "
The new password to be used for this account.
" {} "groupname" {italic} "
The name of an access group into which this account is to be put.
" {} "abstime" {italic} "
The date (and, optionally, the time) at which this user's access is to be terminated.
" {} "Outputs" {bold} "
" {} "ALTER USER" {italic} "
Message returned if the alteration was successful.
" {} "ERROR: alterUser: user 'username' does not exist" {italic} "
Error message returned if the user specified doesn't exist.
" {} "Notes" {italic} "
" {} "ALTER USER" {bold} " statement is a Postgres language extension.
Refer to CREATE/DROP USER to create or remove a user account.
In the current release (v6.5), the IN GROUP clause is parsed but has no affect. When it is fully implemented, it is intended to modify the pg_group relation.
" {} "Compatibility" {bold} "
SQL92
There is no ALTER USER statement in SQL92. The standard leaves the definition of users to the \
implementation."

12
src/bin/pgaccess/lib/help/author.hlp Normal file
View File

@ -0,0 +1,12 @@
.pgaw:Help.f.t insert end \
"The author of PgAccess\n" {title} \
"
My name is Constantin Teodorescu, I'm 36 years old, I have graduated the Faculty of Computers and Automation Bucharest, ROMANIA, I have a 16 year experience in developing applications in various languages, Pascal, C, C++, Visual Basic, Delphi, Perl , Tcl/Tk and Java for different platforms. Currently working as a manager of a team that works in Unix with Java , SQL databases (Oracle, SYBASE) currently using PostgreSQL database for developing professional client/server multi-platform applications (standalone Java or Tcl/Tk ,Java applets) for different customers and various projects (accounting, invoicing, stock inventory).
In present I am the technical manager of FLEX Consulting Braila, a computer shop, software company, networking designer and consultant, ISP provider for Braila city. I'm also a columnist in the romanian technical magazine \"PC-Magazine\" and \"BYTE\".
I have discovered PostgreSQL in 1995 and from the first moment I decided to help it's development writting PgAccess, a graphical interface.
The work has been done using Visual Tcl, in my opinion the best tool for developing Tcl/Tk projects. Visual Tcl is free, more information at http://www.neuron.com/stewart/vtcl/index.html
I'm waiting for any suggestions at e-mail address teo@flex.ro"

35
src/bin/pgaccess/lib/help/begin.hlp Normal file
View File

@ -0,0 +1,35 @@
.pgaw:Help.f.t insert end "BEGIN" {bold} "
By default, Postgres executes transactions in unchained mode (also known as " {} "autocommit" {bold} " in other database systems). In other words, each user statement is executed in its own transaction \
and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done). BEGIN initiates a user transaction in chained mode, i.e. all user \
statements after BEGIN command will be executed in a single transaction until an explicit COMMIT, ROLLBACK or execution abort. Statements in chained mode are executed much faster, \
because transaction start/commit requires significant CPU and disk activity. Execution of multiple statements inside a transaction is also required for consistency when changing several related \
tables. \
The default transaction isolation level in Postgres is READ COMMITTED, where queries inside the transaction see only changes committed before query execution. So, you have to use SET \
TRANSACTION ISOLATION LEVEL SERIALIZABLE just after BEGIN if you need more rigorous transaction isolation. In SERIALIZABLE mode queries will see only changes committed \
before the entire transaction began (actually, before execution of the first DML statement in a serializable transaction). \
If the transaction is committed, Postgres will ensure either that all updates are done or else that none of them are done. Transactions have the standard ACID (atomic, consistent, isolatable, and durable) property.
" {} "Synopsis" {bold} "
" {} "
BEGIN \[ WORK | TRANSACTION \]
" {code} "Notes" {bold} "
The keyword TRANSACTION is just a cosmetic alternative to WORK. Neither keyword need be specified.
Refer to the LOCK statement for further information about locking tables inside a transaction.
Use " {} "COMMIT" {link commit} " or " {} "ROLLBACK" {link rollback} " to terminate a transaction.
" {} "Usage" {bold} "
To begin a user transaction:
" {} "BEGIN WORK;" {italic} "
" {} "Compatibility" {bold} "
BEGIN is a Postgres language extension.
" {} "SQL92" {bold} "
There is no explicit BEGIN WORK command in SQL92; transaction initiation is always implicit and it terminates either with a COMMIT or with a ROLLBACK statement.
Note: Many relational database systems offer an autocommit feature as a convenience.
SQL92 also requires SERIALIZABLE to be the default transaction isolation level. "

22
src/bin/pgaccess/lib/help/close.hlp Normal file
View File

@ -0,0 +1,22 @@
.pgaw:Help.f.t insert end "CLOSE" {bold} " frees the resources associated with an open cursor. After the cursor is closed, no subsequent operations are allowed on it. A cursor should be closed when it is no longer needed. \
An implicit close is executed for every open cursor when a transaction is terminated by \
" {} "COMMIT" {link commit} " or " {} "ROLLBACK" {link rollback} ".
" {} "Synopsis" {bold} "
CLOSE cursor
" {} "Usage" {bold} "
Close the cursor liahona:
CLOSE liahona;
" {} "Compatibility" {bold} "
SQL92
CLOSE is fully compatible with SQL92
" {} "Notes" {bold} "
Postgres does not have an explicit OPEN cursor statement; a cursor is considered open when it is declared. Use the DECLARE statement to declare a cursor."

48
src/bin/pgaccess/lib/help/cluster.hlp Normal file
View File

@ -0,0 +1,48 @@
.pgaw:Help.f.t insert end "CLUSTER" {bold} " instructs Postgres to cluster the class specified by classname approximately based on the index specified by indexname. The index must already have been defined on classname. \
When a class is clustered, it is physically reordered based on the index information. The clustering is static. In other words, as the class is updated, the changes are not clustered. No attempt is \
made to keep new instances or updated tuples clustered. If one wishes, one can recluster manually by issuing the command \
again.
" {} "Synopsis" {bold} "
CLUSTER indexname ON table
" {} "Inputs" {bold} "
" {} "indexname" {italic} "
The name of an index.
" {} "table" {italic} "
The name of a table.
" {} "Outputs" {bold} "
CLUSTER
The clustering was done successfully.
ERROR: relation <tablerelation_number> inherits \"invoice\"
ERROR: Relation x does not exist!
" {} "Usage" {bold} "
Cluster the employees relation on the basis of its salary attribute
CLUSTER emp_ind ON emp
" {} "Notes" {bold} "
The table is actually copied to a temporary table in index order, then renamed back to the original name. For this reason, all grant permissions and other indexes are lost when clustering is \
performed.
In cases where you are accessing single rows randomly within a table, the actual order of the data in the heap table is unimportant. However, if you tend to access some data more than others, \
and there is an index that groups them together, you will benefit from using CLUSTER.
Another place CLUSTER is helpful is in cases where you use an index to pull out several rows from a table. If you are requesting a range of indexed values from a table, or a single indexed \
value that has multiple rows that match, CLUSTER will help because once the index identifies the heap page for the first row that matches, all other rows that match are probably already on the \
same heap page, saving disk accesses and speeding up the query.
There are two ways to cluster data. The first is with the CLUSTER command, which reorders the original table with the ordering of the index you specify. This can be slow on large tables \
because the rows are fetched from the heap in index order, and if the heap table is unordered, the entries are on random pages, so there is one disk page retrieved for every row moved. Postgres \
has a cache, but the majority of a big table will not fit in the cache.
Another way to cluster data is to use
SELECT ... INTO TABLE temp FROM ... ORDER BY ...
This uses the Postgres sorting code in ORDER BY to match the index, and is much faster for unordered data. You then drop the old table, use ALTER TABLE/RENAME to rename temp to \
the old name, and recreate any indexes. The only problem is that OIDs will not be preserved. From then on, CLUSTER should be fast because most of the heap data has already been ordered, \
and the existing index is used. "

17
src/bin/pgaccess/lib/help/commit.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "COMMIT" {bold} " commits the current transaction. All changes made by the transaction become visible to others and are guaranteed to be durable if a crash occurs.
" {} "Synopsis" {bold} "
" {} "
COMMIT \[ WORK | TRANSACTION \]
" {code} "Usage" {bold} "
To make all changes permanent:
COMMIT WORK;
" {} "Notes" {bold} "
The keywords WORK and TRANSACTION are noise and can be omitted.
Use " {} "ROLLBACK" {link rollback} " to abort a transaction."

105
src/bin/pgaccess/lib/help/copy.hlp Normal file
View File

@ -0,0 +1,105 @@
.pgaw:Help.f.t insert end "COPY" {bold} " moves data between Postgres tables and standard Unix files. COPY instructs the Postgres backend to directly read from or write to a file. The file must be directly visible to the backend \
and the name must be specified from the viewpoint of the backend. If stdin or stdout are specified, data flows through the client frontend to the backend.
" {} "Synopsis" {bold} "
" {} "
COPY \[ BINARY \] table \[ WITH OIDS \]
FROM { 'filename' | stdin }
\[ USING DELIMITERS 'delimiter' \]
COPY \[ BINARY \] table \[ WITH OIDS \]
TO { 'filename' | stdout }
\[ USING DELIMITERS 'delimiter' \]
" {code} "Inputs" {bold} "
" {} "BINARY" {italic} "
Changes the behavior of field formatting, forcing all data to be stored or read as binary objects rather than as text.
" {} "table" {italic} "
The name of an existing table.
" {} "WITH OIDS" {italic} "
Copies the internal unique object id (OID) for each row.
" {} "filename" {italic} "
The absolute Unix pathname of the input or output file.
" {} "stdin" {italic} "
Specifies that input comes from a pipe or terminal.
" {} "stdout" {italic} "
Specifies that output goes to a pipe or terminal.
" {} "delimiter" {italic} "
A character that delimits the input or output fields.
" {} "Outputs" {bold} "
" {} "COPY" {italic} "
The copy completed successfully.
" {} "ERROR: error message" {italic} "
The copy failed for the reason stated in the error message.
" {} "Usage" {bold} "
The following example copies a table to standard output, using a vertical bar \(\"|\"\) as the field delimiter:
COPY country TO stdout USING DELIMITERS '|';
To copy data from a Unix file into a table \"country\":
COPY country FROM '/usr1/proj/bray/sql/country_data';
Here is a sample of data suitable for copying into a table from stdin \(so it has the termination sequence on the last \
line\):
AF AFGHANISTAN
AL ALBANIA
DZ ALGERIA
...
ZM ZAMBIA
ZW ZIMBABWE
\.
" {} "File Formats" {bold} "
" {} "Text Format" {italic} "
When COPY TO is used without the BINARY option, the file generated will have each row \(instance\) on a single line, with each column \
\(attribute\) separated by the delimiter character. Embedded delimiter characters will be preceded by a backslash character \
\(\"\\\"\). The attribute values themselves are strings generated by the output function associated with each attribute type. \
The output function for a type should not try to generate the backslash character; this will be handled by COPY itself.
The actual format for each instance is
<attr1><separator><attr2><separator>...<separator><attrn><newline>
The oid is placed on the beginning of the line if WITH OIDS is specified.
If " {} "COPY" {bold} " is sending its output to standard output instead of a file, it will send a backslash\(\"\\\"\) and a period \
\(\".\"\) followed immediately by a newline, on a separate line, when it is done. Similarly, \
if " {} "COPY" {bold} " is reading from standard input, it will expect a backslash \(\"\\\"\) and a period \
\(\".\"\) followed by a newline, as the first three characters on a line to denote end-of-file. However, COPY will \
terminate \(followed by the backend itself\) if a true EOF is encountered before this special end-of-file pattern is found.
The backslash character has other special meanings. NULL attributes are represented as \"\\N\". A literal backslash character is represented as two consecutive backslashes \
\(\"\\\\\"\). A literal tab character is represented as a backslash and a tab. A literal newline character is represented as a backslash and a newline. When loading text data not generated by Postgres, you will need to \
convert backslash characters \(\"\\\"\) to double-backslashes \(\"\\\\\"\) to ensure that they are loaded properly.
" {} "Binary Format" {italic} "
In the case of " {} "COPY BINARY" {bold} ", the first four bytes in the file will be the number of instances in the file. If this number is zero, the \
" {} "COPY BINARY" {bold} " command will read until end of file is encountered. Otherwise, it will stop reading when this number of instances has been read. Remaining data in the file will be ignored. \
The format for each instance in the file is as follows. Note that this format must be followed exactly. Unsigned four-byte integer quantities are called uint32 in the table below.
" {} "Notes" {bold} "
The " {} "BINARY" {bold} " keyword will force all data to be stored/read as binary objects rather than as text. It is somewhat faster than the normal copy command, but is not generally portable, and the files \
generated are somewhat larger, although this factor is highly dependent on the data itself. By default, a text copy uses a tab \
\(\"\\t\"\) character as a delimiter. The delimiter may also be changed to any other single character with the keyword phrase USING DELIMITERS. Characters in data fields which happen to match the delimiter character will be quoted.
You must have select access on any table whose values are read by " {} "COPY" {bold} ", and either insert or update access to a table into which values are being inserted by \
" {} "COPY" {bold} ". The backend also needs appropriate Unix permissions for any file read or written by \
" {} "COPY" {bold} ".
The keyword phrase " {} "USING DELIMITERS" {bold} " specifies a single character to be used for all delimiters between columns. If multiple characters are specified in the delimiter string, only the first \
character is used.
Tip: Do not confuse " {} "COPY" {bold} " with the psql instruction \\copy. "

11
src/bin/pgaccess/lib/help/copyrights.hlp Normal file
View File

@ -0,0 +1,11 @@
.pgaw:Help.f.t insert end \
"Copyrights\n\n" {title} \
"
PostgreSQL is Copyright © 1996-9 by the PostgreSQL Global Development Group, and is distributed under the terms of the Berkeley license.
Postgres95 is Copyright © 1994-5 by the Regents of the University of California. Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
In no event shall the University of California be liable to any party for direct, indirect, special, incidental, or consequential damages, including lost profits, arising out of the use of this software and its documentation, even if the University of California has been advised of the possibility of such damage.
The University of California specifically disclaims any warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The software provided hereunder is on an \"as-is\" basis, and the University of California has no obligations to provide maintainance, support, updates, enhancements, or modifications.
"

90
src/bin/pgaccess/lib/help/create_aggregate.hlp Normal file
View File

@ -0,0 +1,90 @@
.pgaw:Help.f.t insert end "CREATE AGGREGATE" {bold} " allows a user or programmer to extend Postgres functionality by defining new aggregate functions. Some aggregate functions for base types such as \
min\(int4\) and avg(float8) are already provided in the base distribution. If one defines new types or needs an aggregate function not already provided then CREATE AGGREGATE can be used to provide \
the desired features.
An aggregate function can require up to three functions, two state transition functions, sfunc1 and sfunc2:
sfunc1( internal-state1, next-data_item ) ---> next-internal-state1
sfunc2( internal-state2 ) ---> next-internal-state2
and a final calculation function, ffunc:
ffunc(internal-state1, internal-state2) ---> aggregate-value
Postgres creates up to two temporary variables (referred to here as temp1 and temp2) to hold intermediate results used as arguments to the transition functions.
These transition functions are required to have the following properties:
The arguments to sfunc1 must be temp1 of type sfunc1_return_type and column_value of type data_type. The return value must be of type sfunc1_return_type and will be used as
the first argument in the next call to sfunc1.
The argument and return value of sfunc2 must be temp2 of type sfunc2_return_type.
The arguments to the final-calculation-function must be temp1 and temp2 and its return value must be a Postgres base type (not necessarily data_type which had been specified for
BASETYPE).
FINALFUNC should be specified if and only if both state-transition functions are specified.
An aggregate function may also require one or two initial conditions, one for each transition function. These are specified and stored in the database as fields of type text.
" {} "Synopsis" {bold} "
" {} "
CREATE AGGREGATE name \[ AS \]
( BASETYPE = data_type
\[ , SFUNC1 = sfunc1
, STYPE1 = sfunc1_return_type \]
\[ , SFUNC2 = sfunc2
, STYPE2 = sfunc2_return_type \]
\[ , FINALFUNC = ffunc \]
\[ , INITCOND1 = initial_condition1 \]
\[ , INITCOND2 = initial_condition2 \]
)
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The name of an aggregate function to create.
" {} "data_type" {italic} "
The fundamental data type on which this aggregate function operates.
" {} "sfunc1" {italic} "
The state transition function to be called for every non-NULL field from the source column. It takes a variable of type sfunc1_return_type as the first argument and that field as the
second argument.
" {} "sfunc1_return_type" {italic} "
The return type of the first transition function.
" {} "sfunc2" {italic} "
The state transition function to be called for every non-NULL field from the source column. It takes a variable of type sfunc2_return_type as the only argument and returns a variable
of the same type.
" {} "sfunc2_return_type" {italic} "
The return type of the second transition function.
" {} "ffunc" {italic} "
The final function called after traversing all input fields. This function must take two arguments of types sfunc1_return_type and sfunc2_return_type.
" {} "initial_condition1" {italic} "
The initial value for the first transition function argument.
" {} "initial_condition2" {italic} "
The initial value for the second transition function argument.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
Message returned if the command completes successfully.
" {} "Usage" {bold} "
Refer to the chapter on aggregate functions in the PostgreSQL Programmer's Guide on aggregate functions for complete examples of usage.
" {} "Notes" {bold} "
Use " {} "DROP AGGREGATE" {bold} " to drop aggregate functions.
It is possible to specify aggregate functions that have varying combinations of state and final functions. For example, the count aggregate requires SFUNC2 (an incrementing function) but not \
SFUNC1 or FINALFUNC, whereas the sum aggregate requires SFUNC1 (an addition function) but not SFUNC2 or FINALFUNC and the avg aggregate requires both of the above state \
functions as well as a FINALFUNC (a division function) to produce its answer. In any case, at least one state function must be defined, and any SFUNC2 must have a corresponding \
INITCOND2."

59
src/bin/pgaccess/lib/help/create_database.hlp Normal file
View File

@ -0,0 +1,59 @@
.pgaw:Help.f.t insert end "CREATE DATABASE" {bold} " creates a new Postgres database. The creator becomes the administrator of the new database.
" {} "Synopsis" {bold} "
" {} "
CREATE DATABASE name \[ WITH LOCATION = 'dbpath' \]
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The name of a database to create.
" {} "dbpath" {italic} "
An alternate location can be specified as either an environment variable known to the backend server (e.g. 'PGDATA2') or as an absolute path name (e.g. '/usr/local/pgsql/data'). In \
either case, the location must be pre-configured by initlocation.
" {} "Outputs" {bold} "
" {} "CREATEDB" {italic} "
Message returned if the command completes successfully.
" {} "WARN: createdb: database \"name\" already exists." {italic} "
This occurs if database specified already exists.
" {} "ERROR: Unable to create database directory directory" {italic} "
There was a problem with creating the required directory; this operation will need permissions for the postgres user on the specified location.
" {} "Usage" {bold} "
To create a new database:
olly=> create database lusiadas;
To create a new database in an alternate area ~/private_db:
$ mkdir private_db
$ initlocation ~/private_db
Creating Postgres database system directory /home/olly/private_db/base
$ psql olly
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
type \\? for help on slash commands
type \\q to quit
type \\g or terminate with semicolon to execute query
You are currently connected to the database: template1
olly=> create database elsewhere with location = '/home/olly/private_db';
" {} "Bugs" {bold} "
There are security and data integrity issues involved with using alternate database locations specified with absolute path names, and by default only an environment variable known to the \
backend may be specified for an alternate location. See the Administrator's Guide for more information.
" {} "Notes" {bold} "
" {} "CREATE DATABASE" {italic} " is a Postgres language extension.
Use " {} "DROP DATABASE" {italic} " to remove a database. "

69
src/bin/pgaccess/lib/help/create_function.hlp Normal file
View File

@ -0,0 +1,69 @@
.pgaw:Help.f.t insert end \
"Synopsis" {bold} "
CREATE FUNCTION name ( \[ ftype \[, ...\] \] )
RETURNS rtype
AS definition
LANGUAGE 'langname'
" {code} "
name" {italic} "
The name of a function to create.
" {} "ftype" {italic} "
The data type of function arguments.
" {} "rtype" {italic} "
The return data type.
" {} "definition" {italic} "
A string defining the function; the meaning depends on the language. It may be an internal function name, the path to an object file, an SQL query, or text in a procedural language.
" {} "langname" {italic} "
may be 'C', 'sql', 'internal' or 'plname', where 'plname' is the name of a created procedural language. See CREATE LANGUAGE for details.
" {} "Outputs" {bold} "
CREATE
This is returned if the command completes successfully.
CREATE FUNCTION allows a Postgres user to register a function with a database. Subsequently, this user is treated as the owner of the function.
" {} "Notes:" {italic} "Refer to the chapter on functions in the PostgreSQL Programmer's Guide for further information.
Use " {} "DROP FUNCTION" {link drop_function} " to drop user-defined functions.
Postgres allows function \"overloading\"; that is, the same name can be used for several different functions so long as they have distinct argument types. This facility must be used with caution for INTERNAL and C-language functions, however.
Two INTERNAL functions cannot have the same C name without causing errors at link time. To get around that, give them different C names (for example, use the argument types as part of the C names), then specify those names in the AS clause of CREATE FUNCTION. If the AS clause is left empty then CREATE FUNCTION assumes the C name of the function is the same as the SQL name.
For dynamically-loaded C functions, the SQL name of the function must be the same as the C function name, because the AS clause is used to give the path name of the object file containing the C code. In this situation it is best not to try to overload SQL function names. It might work to load a C function that has the same C name as an internal function or another dynamically-loaded function --- or it might not. On some platforms the dynamic loader may botch the load in interesting ways if there is a conflict of C function names. So, even if it works for you today, you might regret overloading names later when you try to run the code somewhere else.
" {} "Usage" {bold} "
To create a simple SQL function:
" {} "
CREATE FUNCTION product_price(int4) RETURNS float8 AS
'SELECT price FROM products where id = \$1'
LANGUAGE 'sql';
SELECT product_price(314) AS answer;
answer
------
15.25
" {code} "
To create a C function, calling a routine from a user-created shared library. This particular routine calculates a check digit and returns TRUE if the check digit in the function parameters is correct. It is intended for use in a CHECK contraint.
" {} "
CREATE FUNCTION ean_checkdigit(bpchar, bpchar) RETURNS bool
AS '/usr1/proj/bray/sql/funcs.so' LANGUAGE 'c';
CREATE TABLE product (
id char(8) PRIMARY KEY,
eanprefix char(8) CHECK (eanprefix ~ '\[0-9\]{2}-\[0-9\]{5}')
REFERENCES brandname(ean_prefix),
eancode char(6) CHECK (eancode ~ '\[0-9\]{6}'),
CONSTRAINT ean CHECK (ean_checkdigit(eanprefix, eancode))
);
" {code}

87
src/bin/pgaccess/lib/help/create_index.hlp Normal file
View File

@ -0,0 +1,87 @@
.pgaw:Help.f.t insert end "CREATE INDEX" {bold} " constructs an index index_name. on the specified table.
Tip: Indexes are primarily used to enhance database performance. But inappropriate use will result in slower performance.
In the first syntax shown above, the key fields for the index are specified as column names; a column may also have an associated operator class. An operator class is used to specify the \
operators to be used for a particular index. For example, a btree index on four-byte integers would use the int4_ops class; this operator class includes comparison functions for four-byte \
integers. The default operator class is the appropriate operator class for that field type.
In the second syntax, an index is defined on the result of a user-defined function func_name applied to one or more attributes of a single class. These functional indexes can be used to obtain \
fast access to data based on operators that would normally require some transformation to apply them to the base data.
" {} "Synopsis" {bold} "
CREATE \[ UNIQUE \] INDEX index_name
ON table \[ USING acc_name \]
( column \[ ops_name\] \[, ...\] )
CREATE \[ UNIQUE \] INDEX index_name
ON table \[ USING acc_name \]
( func_name( column \[, ... \]) ops_name )
" {code} "Inputs" {bold} "
" {} "UNIQUE" {italic} "
Causes the system to check for duplicate values in the table when the index is created \
\(if data already exist\) and each time data is added. Attempts to insert or update non-duplicate \
data will generate an error.
" {} "index_name" {italic} "
The name of the index to be created.
" {} "table" {italic} "
The name of the table to be indexed.
" {} "acc_name" {italic} "
the name of the access method which is to be used for the index. The default access method is BTREE. Postgres provides three access methods for secondary indexes:
BTREE
an implementation of the Lehman-Yao high-concurrency btrees.
RTREE
implements standard rtrees using Guttman's quadratic split algorithm.
HASH
an implementation of Litwin's linear hashing.
" {} "column" {italic} "
The name of a column of the table.
" {} "ops_name" {italic} "
An associated operator class. The following select list returns all ops_names:
" {} "
SELECT am.amname AS acc_name,
opc.opcname AS ops_name,
opr.oprname AS ops_comp
FROM pg_am am, pg_amop amop,
pg_opclass opc, pg_operator opr
WHERE amop.amopid = am.oid AND
amop.amopclaid = opc.oid AND
amop.amopopr = opr.oid
ORDER BY acc_name, ops_name, ops_comp
" {code} "func_name" {italic} "
A user-defined function, which returns a value that can be indexed.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
The message returned if the index is successfully created.
" {} "ERROR: Cannot create index: 'index_name' already exists." {italic} "
This error occurs if it is impossible to create the index.
" {} "Usage" {bold} "
To create a btree index on the field title in the table films:
" {} "
CREATE UNIQUE INDEX title_idx
ON films (title);
" {code} "Notes" {bold} "
Currently, only the BTREE access method supports multi-column indexes. Up to 7 keys may be specified.
Use DROP INDEX to remove an index. "

130
src/bin/pgaccess/lib/help/create_language.hlp Normal file
View File

@ -0,0 +1,130 @@
.pgaw:Help.f.t insert end "CREATE LANGUAGE" {bold} ". Using CREATE LANGUAGE, a Postgres user can register a new language with Postgres. Subsequently, functions and trigger procedures can be defined in this new language. The user must \
have the Postgres superuser privilege to register a new language.
Writing PL handlers
The call handler for a procedural language must be written in a compiler language such as 'C' and registered with Postgres as a function taking no arguments and returning the opaque type, a \
placeholder for unspecified or undefined types.. This prevents the call handler from being called directly as a function from queries.
However, arguments must be supplied on the actual call when a PL function or trigger procedure in the language offered by the handler is to be executed. \
When called from the trigger manager, the only argument is the object ID from the procedure's pg_proc entry. All other information from the trigger manager is found in the global \
CurrentTriggerData pointer.
When called from the function manager, the arguments are the object ID of the procedure's pg_proc entry, the number of arguments given to the PL function, the arguments in a \
FmgrValues structure and a pointer to a boolean where the function tells the caller if the return value is the SQL NULL value.
It's up to the call handler to fetch the pg_proc entry and to analyze the argument and return types of the called procedure. The AS clause from the CREATE FUNCTION of the procedure will \
be found in the prosrc attribute of the pg_proc table entry. This may be the source text in the procedural language itself (like for PL/Tcl), a pathname to a file or anything else that tells the call \
handler what to do in detail.
" {} "Synopsis" {bold} "
CREATE \[ TRUSTED \] PROCEDURAL LANGUAGE 'langname'
HANDLER call_handler
LANCOMPILER 'comment'
" {code} "Inputs" {bold} "
" {} "TRUSTED" {italic} "
TRUSTED specifies that the call handler for the language is safe; that is, it offers an unprivileged user no functionality to bypass access restrictions. If this keyword is omitted when
registering the language, only users with the Postgres superuser privilege can use this language to create new functions (like the 'C' language).
" {} "langname" {italic} "
The name of the new procedural language. The language name is case insensitive. A procedural language cannot override one of the built-in languages of Postgres.
" {} "HANDLER call_handler" {italic} "
call_handler is the name of a previously registered function that will be called to execute the PL procedures.
" {} "comment" {italic} "
The LANCOMPILER argument is the string that will be inserted in the LANCOMPILER attribute of the new pg_language entry. At present, Postgres does not use this attribute in any way.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
This message is returned if the language is successfully created.
" {} "ERROR: PL handler function funcname\(\) doesn't exist" {italic} "
This error is returned if the function funcname() is not found.
" {} "Usage" {bold} "
This is a template for a PL handler written in 'C':
" {} "
#include \"executor/spi.h\"
#include \"commands/trigger.h\"
#include \"utils/elog.h\"
#include \"fmgr.h\" /* for FmgrValues struct */
#include \"access/heapam.h\"
#include \"utils/syscache.h\"
#include \"catalog/pg_proc.h\"
#include \"catalog/pg_type.h\"
Datum
plsample_call_handler\(
Oid prooid,
int pronargs,
FmgrValues *proargs,
bool *isNull\)
\{
Datum retval;
TriggerData *trigdata;
if \(CurrentTriggerData == NULL\) \{
/*
* Called as a function
*/
retval = ...
\} else \{
/*
* Called as a trigger procedure
*/
trigdata = CurrentTriggerData;
CurrentTriggerData = NULL;
retval = ...
\}
*isNull = false;
return retval;
\}
" {code} "
Only a few thousand lines of code have to be added instead of the dots to complete the PL call handler. See CREATE FUNCTION for information on how to compile it into a loadable module .
The following commands then register the sample procedural language:
" {} "
CREATE FUNCTION plsample_call_handler () RETURNS opaque
AS '/usr/local/pgsql/lib/plsample.so'
LANGUAGE 'C';
CREATE PROCEDURAL LANGUAGE 'plsample'
HANDLER plsample_call_handler
LANCOMPILER 'PL/Sample';
" {code} "Notes" {bold} "
Use " {} "CREATE FUNCTION" {bold} " to create a function.
Use DROP LANGUAGE to drop procedural languages.
Refer to the table pg_language for further information:
Table = pg_language
" {} "
+-----------------+----------+-------+
| Field | Type | Length|
+-----------------+----------+-------+
| lanname | name | 32 |
| lancompiler | text | var |
+-----------------+----------+-------+
lanname |lancompiler
--------+--------------
internal|n/a
lisp |/usr/ucb/liszt
C |/bin/cc
sql |postgres
" {code} "
" {} "Restrictions" {bold} "
Since the call handler for a procedural language must be registered with Postgres in the 'C' language, it inherits all the capabilities and restrictions of 'C' functions.
"

145
src/bin/pgaccess/lib/help/create_operator.hlp Normal file
View File

@ -0,0 +1,145 @@
.pgaw:Help.f.t insert end "CREATE OPERATOR" {bold} " defines a new operator, name. The user who defines an operator becomes its owner.
The operator name is a sequence of up to thirty two (32) characters in any combination from the following:
+ - * / < > = ~ ! @ # % ^ & | ` ? $ :
" {} "Note:" {bold} " No alphabetic characters are allowed in an operator name. This enables Postgres to parse SQL input into tokens without requiring spaces between each token.
The operator \"!=\" is mapped to \"<>\" on input, so they are therefore equivalent.
At least one of LEFTARG and RIGHTARG must be defined. For binary operators, both should be defined. For right unary operators, only LEFTARG should be defined, while for left unary \
operators only RIGHTARG should be defined.
Also, the func_name procedure must have been previously defined using CREATE FUNCTION and must be defined to accept the correct number of arguments (either one or two). \
The commutator operator should be identified if one exists, so that Postgres can reverse the order of the operands if it wishes. For example, the operator area-less-than, <<<, would probably \
have a commutator operator, area-greater-than, >>>. Hence, the query optimizer could freely convert:
\"0,0,1,1\"::box >>> MYBOXES.description
to
MYBOXES.description <<< \"0,0,1,1\"::box
This allows the execution code to always use the latter representation and simplifies the query optimizer somewhat.
Similarly, if there is a negator operator then it should be identified. Suppose that an operator, area-equal, ===, exists, as well as an area not equal, !==. The negator link allows the query \
optimizer to simplify
NOT MYBOXES.description === \"0,0,1,1\"::box
to
MYBOXES.description !== \"0,0,1,1\"::box
If a commutator operator name is supplied, Postgres searches for it in the catalog. If it is found and it does not yet have a commutator itself, then the commutator's entry is updated to have the \
newly created operator as its commutator. This applies to the negator, as well.
This is to allow the definition of two operators that are the commutators or the negators of each other. The first operator should be defined without a commutator or negator (as appropriate). \
When the second operator is defined, name the first as the commutator or negator. The first will be updated as a side effect.(As of Postgres 6.5, it also works to just have both operators refer to \
each other.)
The next three specifications are present to support the query optimizer in performing joins. Postgres can always evaluate a join (i.e., processing a clause with two tuple variables separated by \
an operator that returns a boolean) by iterative substitution \[WONG76\]. In addition, Postgres can use a hash-join algorithm along the lines of \
\[SHAP86\]; however, it must know whether this \
strategy is applicable. The current hash-join algorithm is only correct for operators that represent equality tests; furthermore, equality of the datatype must mean bitwise equality of the \
representation of the type. (For example, a datatype that contains unused bits that don't matter for equality tests could not be hashjoined.) The HASHES flag indicates to the query optimizer \
that a hash join may safely be used with this operator.
Similarly, the two sort operators indicate to the query optimizer whether merge-sort is a usable join strategy and which operators should be used to sort the two operand classes. Sort operators \
should only be provided for an equality operator, and they should refer to less-than operators for the left and right side data types respectively.
If other join strategies are found to be practical, Postgres will change the optimizer and run-time system to use them and will require additional specification when an operator is defined. \
Fortunately, the research community invents new join strategies infrequently, and the added generality of user-defined join strategies was not felt to be worth the complexity involved.
The last two pieces of the specification are present so the query optimizer can estimate result sizes. If a clause of the form:
MYBOXES.description <<< \"0,0,1,1\"::box
is present in the qualification, then Postgres may have to estimate the fraction of the instances in MYBOXES that satisfy the clause. The function res_proc must be a registered function \
(meaning it is already defined using CREATE FUNCTION) which accepts arguments of the correct data types and returns a floating point number. The query optimizer simply calls this function, \
passing the parameter \"0,0,1,1\" and multiplies the result by the relation size to get the desired expected number of instances.
Similarly, when the operands of the operator both contain instance variables, the query optimizer must estimate the size of the resulting join. The function join_proc will return another floating \
point number which will be multiplied by the cardinalities of the two classes involved to compute the desired expected result size.
The difference between the function
my_procedure_1 (MYBOXES.description, \"0,0,1,1\"::box)
and the operator
MYBOXES.description === \"0,0,1,1\"::box
is that Postgres attempts to optimize operators and can decide to use an index to restrict the search space when operators are involved. However, there is no attempt to optimize functions, and \
they are performed by brute force. Moreover, functions can have any number of arguments while operators are restricted to one or two.
" {} "Synopsis" {bold} "
CREATE OPERATOR name (
PROCEDURE = func_name
\[, LEFTARG = type1 \]
\[, RIGHTARG = type2 \]
\[, COMMUTATOR = com_op \]
\[, NEGATOR = neg_op \]
\[, RESTRICT = res_proc \]
\[, JOIN = join_proc \]
\[, HASHES \]
\[, SORT1 = left_sort_op \]
\[, SORT2 = right_sort_op \]
)
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The operator to be defined. See below for allowable characters.
" {} "func_name" {italic} "
The function used to implement this operator.
" {} "type1" {italic} "
The type for the left-hand side of the operator, if any. This option would be omitted for a right-unary operator.
" {} "type2" {italic} "
The type for the right-hand side of the operator, if any. This option would be omitted for a left-unary operator.
" {} "com_op" {italic} "
The commutator for this operator.
" {} "neg_op" {italic} "
The negator of this operator.
" {} "res_proc" {italic} "
The restriction selectivity estimator function for this operator.
" {} "join_proc" {italic} "
The join selectivity estimator function for this operator.
" {} "HASHES" {italic} "
Indicates this operator can support a hash-join algorithm.
" {} "left_sort_op" {italic} "
Operator that sorts the left-hand data type of this operator.
" {} "right_sort_op" {italic} "
Operator that sorts the right-hand data type of this operator.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
Message returned if the operator is successfully created.
" {} "Usage" {bold} "
The following command defines a new operator, area-equality, for the BOX data type.
" {} "
CREATE OPERATOR === (
LEFTARG = box,
RIGHTARG = box,
PROCEDURE = area_equal_procedure,
COMMUTATOR = ===,
NEGATOR = !==,
RESTRICT = area_restriction_procedure,
JOIN = area_join_procedure,
HASHES,
SORT1 = <<<,
SORT2 = <<<)
" {code} "Notes" {bold} "
Refer to the chapter on operators in the PostgreSQL User's Guide for further information. Refer to DROP OPERATOR to delete user-defined operators from a database.
"

132
src/bin/pgaccess/lib/help/create_rule.hlp Normal file
View File

@ -0,0 +1,132 @@
.pgaw:Help.f.t insert end "CREATE RULE" {bold} " The semantics of a rule is that at the time an individual instance is accessed, updated, inserted or deleted, there is a current instance (for retrieves, updates and deletes) and a new instance (for \
updates and appends). If the event specified in the ON clause and the condition specified in the WHERE clause are true for the current instance, the action part of the rule is executed. First, \
however, values from fields in the current instance and/or the new instance are substituted for current.attribute-name and new.attribute-name.
The action part of the rule executes with the same command and transaction identifier as the user command that caused activation.
" {} "Synopsis" {bold} "
CREATE RULE name
AS ON event
TO object \[ WHERE condition \]
DO \[ INSTEAD \] \[ action | NOTHING \]
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The name of a rule to create.
" {} "event" {italic} "
Event is one of select, update, delete or insert.
" {} "object" {italic} "
Object is either table or table.column.
" {} "condition" {italic} "
Any SQL WHERE clause. new or current can appear instead of an instance variable whenever an instance variable is permissible in SQL.
" {} "action" {italic} "
Any SQL statement. new or current can appear instead of an instance variable whenever an instance variable is permissible in SQL.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
Message returned if the rule is successfully created.
" {} "Usage" {bold} "
Make Sam get the same salary adjustment as Joe:
" {} "
create rule example_1 as
on update EMP.salary where current.name = \"Joe\"
do update EMP (salary = new.salary)
where EMP.name = \"Sam\"
" {code} "
At the time Joe receives a salary adjustment, the event will become true and Joe's current instance and proposed new instance are available to the execution routines. Hence, his new salary is \
substituted into the action part of the rule which is subsequently executed. This propagates Joe's salary on to Sam.
Make Bill get Joe's salary when it is accessed:
" {} "
create rule example_2 as
on select to EMP.salary
where current.name = \"Bill\"
do instead
select (EMP.salary) from EMP
where EMP.name = \"Joe\"
" {code} "
Deny Joe access to the salary of employees in the shoe department (current_user returns the name of the current user):
" {} "
create rule example_3 as
on select to EMP.salary
where current.dept = \"shoe\" and current_user = \"Joe\"
do instead nothing
" {code} "
Create a view of the employees working in the toy department.
" {} "
create TOYEMP(name = char16, salary = int4)
create rule example_4 as
on select to TOYEMP
do instead
select (EMP.name, EMP.salary) from EMP
where EMP.dept = \"toy\"
" {code} "
All new employees must make 5,000 or less
" {} "
create rule example_5 as
on insert to EMP where new.salary > 5000
do update newset salary = 5000
" {code} "Notes" {bold} "
A caution about SQL rules is in order. If the same class name or instance variable appears in the event, the condition and the action parts of a rule, they are all considered different tuple \
variables. More accurately, new and current are the only tuple variables that are shared between these clauses. For example, the following two rules have the same semantics:
" {} "
on update to EMP.salary where EMP.name = \"Joe\"
do update EMP ( ... ) where ...
on update to EMP-1.salary where EMP-2.name = \"Joe\"
do update EMP-3 ( ... ) where ...
" {code} "
Each rule can have the optional tag INSTEAD. Without this tag, action will be performed in addition to the user command when the event in the condition part of the rule occurs. Alternately, \
the action part will be done instead of the user command. In this later case, the action can be the keyword NOTHING.
When choosing between the rewrite and instance rule systems for a particular rule application, remember that in the rewrite system, current refers to a relation and some qualifiers whereas in \
the instance system it refers to an instance (tuple).
It is very important to note that the rewrite rule system will neither detect nor process circular rules. For example, though each of the following two rule definitions are accepted by Postgres, the \
retrieve command will cause Postgres to crash:
Example 14-1. Example of a circular rewrite rule combination.
" {} "
create rule bad_rule_combination_1 as
on select to EMP
do instead select to TOYEMP
create rule bad_rule_combination_2 as
on select to TOYEMP
do instead select to EMP
" {code} "
This attempt to retrieve from EMP will cause Postgres to crash.
" {} "
select * from EMP
" {code} "
You must have rule definition access to a class in order to define a rule on it. Use GRANT and REVOKE to change permissions.
" {} "Bugs" {bold} "
The object in a SQL rule cannot be an array reference and cannot have parameters.
Aside from the \"oid\" field, system attributes cannot be referenced anywhere in a rule. Among other things, this means that functions of instances (e.g., \"foo(emp)\" where \
\"emp\" is a class) cannot be called anywhere in a rule.
The rule system stores the rule text and query plans as text attributes. This implies that creation of rules may fail if the rule plus its various internal representations exceed some value that is on \
the order of one page (8KB). "

42
src/bin/pgaccess/lib/help/create_sequence.hlp Normal file
View File

@ -0,0 +1,42 @@
.pgaw:Help.f.t insert end \
"CREATE SEQUENCE" {bold} " will enter a new sequence number generator into the current data base. This involves creating and initialising a new single-row table with the name seqname. The generator will be \"owned\" by the user issuing the command.
After a sequence is created, you may use the function nextval(seqname) to get a new number from the sequence. The function currval('seqname') may be used to determine the number returned by the last call to nextval(seqname) for the specified sequence in the current session. The function setval('seqname', newvalue) may be used to set the current value of the specified sequence. The next call to nextval(seqname) will return the given value plus the sequence increment.
" {} "Synopsis" {bold} "
CREATE SEQUENCE seqname
\[ INCREMENT increment \]
\[ MINVALUE minvalue \]
\[ MAXVALUE maxvalue \]
\[ START start \]
\[ CACHE cache \]
\[ CYCLE \]
" {code} "
" {} "Inputs" {bold} "
" {} "seqname" {italic} "
The name of a sequence to be created.
" {} "increment" {italic} "
The INCREMENT increment clause is optional. A positive value will make an ascending sequence, a negative one a descending sequence. The default value is one (1).
" {} "minvalue" {italic} "
The optional clause MINVALUE minvalue determines the minimum value a sequence can generate. The defaults are 1 and -2147483647 for ascending and descending sequences, respectively.
" {} "maxvalue" {italic} "
Use the optional clause MAXVALUE maxvalue to determine the maximum value for the sequence. The defaults are 2147483647 and -1 for ascending and descending sequences, respectively.
" {} "start" {italic} "
The optional START start clause enables the sequence to begin anywhere. The default starting value is minvalue for ascending sequences and maxvalue for descending ones.
" {} "cache" {italic} "
The CACHE cache option enables sequence numbers to be preallocated and stored in memory for faster access. The minimum value is 1 (only one value can be generated at a time, i.e. no cache) and this is also the default.
" {} "CYCLE" {italic} "
The optional CYCLE keyword may be used to enable the sequence to continue when the maxvalue or minvalue has been reached by an ascending or descending sequence respectively. If the limit is reached, the next number generated will be whatever the minvalue or maxvalue is, as appropriate.
" {} "CAUTION" {title} "
Unexpected results may be obtained if a cache setting greater than one is used for a sequence object that will be used concurrently by multiple backends. Each backend will allocate \"cache\" successive sequence values during one access to the sequence object and increase the sequence object's last_value accordingly. Then, the next cache-1 uses of nextval within that backend simply return the preallocated values without touching the shared object. So, numbers allocated but not used in the current session will be lost. Furthermore, although multiple backends are guaranteed to allocate distinct sequence values, the values may be generated out of sequence when all the backends are considered. (For example, with a cache setting of 10, backend A might reserve values 1..10 and return nextval=1, then backend B might reserve values 11..20 and return nextval=11 before backend A has generated nextval=2.) Thus, with a cache setting of one it is safe to assume that nextval values are generated sequentially; with a cache setting greater than one you should only assume that the nextval values are all distinct, not that they are generated purely sequentially. Also, last_value will reflect the latest value reserved by any backend, whether or not it has yet been returned by nextval.
CREATE SEQUENCE is a Postgres language extension. There is no CREATE SEQUENCE statement in SQL92."

39
src/bin/pgaccess/lib/help/create_table.hlp Normal file
View File

@ -0,0 +1,39 @@
.pgaw:Help.f.t insert end \
"CREATE TABLE" {bold} "
CREATE \[ TEMPORARY | TEMP \] TABLE table (
column type
\[ NULL | NOT NULL \] \[ UNIQUE \] \[ DEFAULT value \]
\[column_constraint_clause | PRIMARY KEY } \[ ... \] \]
\[, ... ]
\[, PRIMARY KEY ( column \[, ...\] ) \]
\[, CHECK ( condition ) \]
\[, table_constraint_clause \]
) \[ INHERITS ( inherited_table \[, ...\] ) \]
" {code} "
TEMPORARY
The table is created only for this session, and is automatically dropped on session exit. Existing permanent tables with the same name are not visible while the temporary table exists.
" {} "
table" {italic} "
The name of a new table to be created.
" {} "
column" {italic} "
The name of a column.
" {} "
type" {italic} "
The type of the column. This may include array specifiers. Refer to the PostgreSQL User's Guide for further information about data types and arrays.
" {} "
DEFAULT value" {italic} "
A default value for a column. See the DEFAULT clause for more information.
" {} "
column_constraint_clause" {italic} "
The optional column constraint clauses specify a list of integrity constraints or tests which new or updated entries must satisfy for an insert or update operation to succeed. Each constraint must evaluate to a boolean expression. Although SQL92 requires the column_constraint_clause to refer to that column only, Postgres allows multiple columns to be referenced within a single column constraint. See the column constraint clause for more information.
" {} "
table_constraint_clause" {italic} "
The optional table CONSTRAINT clause specifies a list of integrity constraints which new or updated entries must satisfy for an insert or update operation to succeed. Each constraint must evaluate to a boolean expression. Multiple columns may be referenced within a single constraint. Only one PRIMARY KEY clause may be specified for a table; PRIMARY KEY column (a table constraint) and PRIMARY KEY (a column constraint) are mutually exclusive.. See the table constraint clause for more information.
" {} "
INHERITS inherited_table" {italic} "
The optional INHERITS clause specifies a collection of table names from which this table automatically inherits all fields. If any inherited field name appears more than once, Postgres reports an error. Postgres automatically allows the created table to inherit functions on tables above it in the inheritance hierarchy.
Aside: Inheritance of functions is done according to the conventions of the Common Lisp Object System (CLOS).
"

20
src/bin/pgaccess/lib/help/create_table_as.hlp Normal file
View File

@ -0,0 +1,20 @@
.pgaw:Help.f.t insert end "CREATE TABLE AS" {bold} " CREATE TABLE AS enables a table to be created from the contents of an existing table. It has functionality equivalent to SELECT TABLE INTO, but with perhaps a more obvious syntax.
" {} "Synopsis" {bold} "
" {} "
CREATE TABLE table \[ (column \[, ...\] ) \]
AS select_clause
" {code} "Inputs" {bold} "
" {} "table" {italic} "
The name of a new table to be created.
" {} "column" {italic} "
The name of a column. Multiple column names can be specified using a comma-delimited list of column names.
" {} "select_clause" {italic} "
A valid query statement. Refer to SELECT for a description of the allowed syntax.
" {} "Outputs" {bold} "
Refer to CREATE TABLE and SELECT for a summary of possible output messages. "

80
src/bin/pgaccess/lib/help/create_trigger.hlp Normal file
View File

@ -0,0 +1,80 @@
.pgaw:Help.f.t insert end "CREATE TRIGGER" {bold} " will enter a new trigger into the current data base. The trigger will be associated with the relation relname and will execute the specified function funcname.
The trigger can be specified to fire either before the operation is attempted on a tuple (before constraints are checked and the INSERT, UPDATE or DELETE is attempted) or after the operation \
has been attempted (e.g. after constraints are checked and the INSERT, UPDATE or DELETE has completed). If the trigger fires before the event, the trigger may skip the operation for the \
current tuple, or change the tuple being inserted (for INSERT and UPDATE operations only). If the trigger fires after the event, all changes, including the last insertion, update, or deletion, are \
\"visible\" to the trigger.
Refer to the chapters on SPI and Triggers in the PostgreSQL Programmer's Guide for more information.
" {} "Synopsis" {bold} "
CREATE TRIGGER name \{ BEFORE | AFTER \}
\{ event \[OR ...\] \}
ON table FOR EACH \{ ROW | STATEMENT \}
EXECUTE PROCEDURE funcname ( arguments )
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The name of an existing trigger.
" {} "table" {italic} "
The name of a table.
" {} "event" {italic} "
One of INSERT, DELETE or UPDATE.
" {} "funcname" {italic} "
A user-supplied function.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
This message is returned if the trigger is successfully created.
" {} "Usage" {bold} "
Check if the specified distributor code exists in the distributors table before appending or updating a row in the table films:
" {} "
CREATE TRIGGER if_dist_exists
BEFORE INSERT OR UPDATE ON films FOR EACH ROW
EXECUTE PROCEDURE check_primary_key ('did', 'distributors', 'did');
" {code} "
Before cancelling a distributor or updating its code, remove every reference to the table films:
" {} "
CREATE TRIGGER if_film_exists
BEFORE DELETE OR UPDATE ON distributors FOR EACH ROW
EXECUTE PROCEDURE check_foreign_key (1, 'CASCADE', 'did', 'films', 'did');
" {code} "Compatibility" {bold} "
" {} "SQL92" {italic} "
There is no CREATE TRIGGER in SQL92.
The second example above may also be done by using a FOREIGN KEY constraint as in:
" {} "
CREATE TABLE distributors (
did DECIMAL(3),
name VARCHAR(40),
CONSTRAINT if_film_exists
FOREIGN KEY(did) REFERENCES films
ON UPDATE CASCADE ON DELETE CASCADE
);
" {code} "
However, foreign keys are not yet implemented (as of version 6.4) in Postgres.
" {} "Notes" {bold} "
" {} "CREATE TRIGGER" {italic} " is a Postgres language extension.
Only the relation owner may create a trigger on this relation.
As of the current release (v6.4), STATEMENT triggers are not implemented.
Refer to DROP TRIGGER for information on how to remove triggers. "

24
src/bin/pgaccess/lib/help/create_type.hlp Normal file
View File

@ -0,0 +1,24 @@
.pgaw:Help.f.t insert end "CREATE TYPE" {bold} " allows the user to register a new user data type with Postgres for use in the current data base. The user who defines a type becomes its owner. Typename is the name of the new \
type and must be unique within the types defined for this database.
" {} "Synopsis" {bold} "
CREATE TYPE typename (
INPUT = input_function
, OUTPUT = output_function
, INTERNALLENGTH = (internallength | VARIABLE)
\[ , EXTERNALLENGTH = (externallength | VARIABLE) \]
\[ , ELEMENT = element \]
\[ , DELIMITER = delimiter \]
\[ , DEFAULT = \"default\" \]
\[ , SEND = send_function \]
\[ , RECEIVE = receive_function \]
\[ , PASSEDBYVALUE \]
)
" {code} "Notes" {bold} "
Refer to DROP TYPE to remove an existing type.
See also CREATE FUNCTION, CREATE OPERATOR and the chapter on Large Objects in the PostgreSQL Programmer's Guide.
"

50
src/bin/pgaccess/lib/help/create_user.hlp Normal file
View File

@ -0,0 +1,50 @@
.pgaw:Help.f.t insert end "CREATE USER" {bold} " will add a new user to an instance of Postgres.
The new user will be given a usesysid of: 'SELECT MAX(usesysid) + 1 FROM pg_shadow'. This means that Postgres users' usesysids will not correspond to their operating system(OS) \
user ids. The exception to this rule is the 'postgres' user, whose OS user id is used as the usesysid during the initdb process. If you still want the OS user id and the usesysid to match for any \
given user, use the \"createuser\" script provided with the Postgres distribution.
" {} "Synopsis" {bold} "
CREATE USER username
\[ WITH PASSWORD password \]
\[ CREATEDB | NOCREATEDB \]
\[ CREATEUSER | NOCREATEUSER \]
\[ IN GROUP groupname \[, ...\] \]
\[ VALID UNTIL 'abstime' \]
" {code} "Usage" {bold} "
Create a user with no password:
" {} " CREATE USER jonathan
" {code} "
Create a user with a password:
" {} " CREATE USER davide WITH PASSWORD jw8s0F4
" {code} "
Create a user with a password, whose account is valid until the end of 2001. Note that after one second has ticked in 2002, the account is not valid:
" {} " CREATE USER miriam WITH PASSWORD jw8s0F4 VALID UNTIL 'Jan 1 2002'
" {code} "
Create an account where the user can create databases:
" {} " CREATE USER manuel WITH PASSWORD jw8s0F4 CREATEDB
" {code} "Notes" {bold} "
CREATE USER statement is a Postgres language extension.
Use DROP USER or ALTER USER statements to remove or modify a user account.
Refer to the pg_shadow table for further information.
" {} "
Table = pg_shadow
+--------------------------+--------------------------+-------+
| Field | Type | Length|
+--------------------------+--------------------------+-------+
| usename | name | 32 |
| usesysid | int4 | 4 |
| usecreatedb | bool | 1 |
| usetrace | bool | 1 |
| usesuper | bool | 1 |
| usecatupd | bool | 1 |
| passwd | text | var |
| valuntil | abstime | 4 |
+--------------------------+--------------------------+-------+
" {code}

27
src/bin/pgaccess/lib/help/create_view.hlp Normal file
View File

@ -0,0 +1,27 @@
.pgaw:Help.f.t insert end "CREATE VIEW" {bold} " will define a view of a table. This view is not physically materialized. Specifically, a query rewrite retrieve rule is automatically generated to support retrieve operations on \
views.
" {} "Synopsis" {bold} "
CREATE VIEW view
AS SELECT query
" {} "Usage" {bold} "
Create a view consisting of all Comedy films:
" {} "
CREATE VIEW kinds AS
SELECT *
FROM films
WHERE kind = 'Comedy';
SELECT * FROM kinds;
code |title |did| date_prod|kind |len
-----+-------------------------+---+----------+----------+------
UA502|Bananas |105|1971-07-13|Comedy | 01:22
C_701|There's a Girl in my Soup|107|1970-06-11|Comedy | 01:36
" {code} "Notes" {bold} "
Use the DROP VIEW statement to drop views. "

48
src/bin/pgaccess/lib/help/data_types.hlp Normal file
View File

@ -0,0 +1,48 @@
.pgaw:Help.f.t configure -tabs {130 300 450}
.pgaw:Help.f.t insert end \
"Data types\n\n" {title} \
"Postgres has a rich set of native data types available to users. Users may add new types to Postgres using the DEFINE TYPE command described elsewhere.
In the context of data types, the following sections will discuss SQL standards compliance, porting issues, and usage. Some Postgres types correspond directly to SQL92-compatible types. In other cases, data types defined by SQL92 syntax are mapped directly into native Postgres types. Many of the built-in types have obvious external formats. However, several types are either unique to Postgres, such as open and closed paths, or have several possibilities for formats, such as the date and time types.
" {} \
"Postgres Type\tSQL92 or SQL3 Type\tDescription\n" {bold} \
"bool\tboolean\tlogical boolean (true/false)
box\t\trectangular box in 2D plane\tchar(n)
character(n)\t\tfixed-length character string
cidr\t\tIP version 4 network or host address
circle\t\tcircle in 2D plane
date\tdate\tcalendar date without time of day
float4/8\tfloat(p)\tfloating-point number with precision p
float8\treal, double precision\tdouble-precision floating-point number
inet\t\tIP version 4 network or host address
int2\tsmallint\tsigned two-byte integer
int4\tint, integer\tsigned 4-byte integer
int4\tdecimal(p,s)\texact numeric for p <= 9, s = 0
int4\tnumeric(p,s)\texact numeric for p == 9, s = 0
int8\t\tsigned 8-byte integer
line\t\tinfinite line in 2D plane
lseg\t\tline segment in 2D plane
money\tdecimal(9,2)\tUS-style currency
path\t\topen and closed geometric path in 2D plane
point\t\tgeometric point in 2D plane
polygon\t\tclosed geometric path in 2D plane
serial\t\tunique id for indexing and cross-reference
time\ttime\ttime of day
timespan\tinterval\tgeneral-use time span
timestamp\ttimestamp with time zone\tdate/time
varchar(n)\tcharacter varying(n)\tvariable-length character string
Note: The cidr and inet types are designed to handle any IP type but only ipv4 is handled in the current implementation. Everything here that talks about ipv4 will apply to ipv6 in a future release.
" {} \
"Postgres Function Constants
Postgres Function\tSQL92 Constant\tDescription" {bold} \
"
getpgusername()\tcurrent_user\tuser name in current session
date('now')\tcurrent_date\tdate of current transaction
time('now')\tcurrent_time\ttime of current transaction
timestamp('now')\tcurrent_timestamp\tdate and time of current transaction
" {}

58
src/bin/pgaccess/lib/help/datefunc.hlp Normal file
View File

@ -0,0 +1,58 @@
.pgaw:Help.f.t insert end \
"DateTime functions\n\n" {title} \
"abstime(datetime) " {bold} "
Returns: abstime
convert to abstime
" {} "age(datetime,datetime) " {bold} "
Returns: timespan
preserve months and years
" {} "datetime(abstime) " {bold} "
Returns: datetime
convert to datetime
" {} "datetime(date) " {bold} "
Returns: datetime
convert to datetime
" {} "datetime(date,time) " {bold} "
Returns: datetime
convert to datetime
" {} "date_part(text,datetime) " {bold} "
Returns: float8
portion of date
" {} "date_part(text,timespan) " {bold} "
Returns: float8
portion of time
" {} "date_trunc(text,datetime) " {bold} "
Returns: datetime
truncate date
" {} "isfinite(abstime) " {bold} "
Returns: bool
a finite time?
" {} "isfinite(datetime) " {bold} "
Returns: bool
a finite time?
" {} "isfinite(timespan) " {bold} "
Returns: bool
a finite time?
" {} "reltime(timespan) " {bold} "
Returns: reltime
convert to reltime
" {} "timespan(reltime) " {bold} "
Returns: timespan
convert to timespan
" {} \
"PostgreSQL functions\n" {link pgfunctions} \
"Next - geometric functions" {link geomfunc}

29
src/bin/pgaccess/lib/help/declare.hlp Normal file
View File

@ -0,0 +1,29 @@
.pgaw:Help.f.t insert end "DECLARE" {bold} " allows a user to create cursors, which can be used to retrieve a small number of rows at a time out of a larger query. Cursors can return data either in text or in binary foramt.
Normal cursors return data in text format, either ASCII or another encoding scheme depending on how the Postgres backend was built. Since data is stored natively in binary format, the system \
must do a conversion to produce the text format. In addition, text formats are often larger in size than the corresponding binary format. Once the information comes back in text form, the client \
application may have to convert it to a binary format to manipulate it anyway.
BINARY cursors give you back the data in the native binary representation. So binary cursors will tend to be a little faster since they suffer less conversion overhead.
" {} "Synopsis" {bold} "
DECLARE cursor \[ BINARY \] \[ INSENSITIVE \] \[ SCROLL \]
CURSOR FOR query
\[ FOR \[ READ ONLY | UPDATE \[ OF column \[, ...\] \] \]
" {code} "Usage" {bold} "
To declare a cursor:
" {} "
DECLARE liahona CURSOR
FOR SELECT * FROM films;
" {code} "Notes" {bold} "
Cursors are only available in transactions.
Postgres does not have an explicit OPEN cursor statement; a cursor is considered to be open when it is declared.
Note: In SQL92 cursors are only available in embedded applications. ecpg, the embedded SQL preprocessor for Postgres, supports the SQL92 conventions, including those \
involving DECLARE and OPEN statements. "

43
src/bin/pgaccess/lib/help/delete.hlp Normal file
View File

@ -0,0 +1,43 @@
.pgaw:Help.f.t insert end "DELETE" {bold} " emoves rows which satisfy the WHERE condition, from the specified table. \
If the condition is absent, the effect is to delete all rows in the table. The result is a valid, but empty table. \
You must have write access to the table in order to modify it, as well as read access to any table whose values are read in the condition.
" {} "Synopsis" {bold} "
" {} "
DELETE FROM table \[ WHERE condition \]
" {code} "Usage" {bold} "
Remove all films but musicals:
" {} "
DETETE FROM films WHERE kind <> 'Musical';
SELECT * FROM films;
code |title |did| date_prod|kind |len
-----+-------------------------+---+----------+----------+------
UA501|West Side Story |105|1961-01-03|Musical | 02:32
TC901|The King and I |109|1956-08-11|Musical | 02:13
WD101|Bed Knobs and Broomsticks|111| |Musical | 01:57
(3 rows)
Clear the table films:
DELETE FROM films;
SELECT * FROM films;
code|title|did|date_prod|kind|len
----+-----+---+---------+----+---
(0 rows)
" {code} "Compatibility" {bold} "
SQL92
SQL92 allows a positioned DELETE statement:
DELETE FROM table WHERE CURRENT OF cursor
where cursor identifies an open cursor. Interactive cursors in Postgres are read-only. "

17
src/bin/pgaccess/lib/help/drop_aggregate.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP AGGREGATE" {bold} " will remove all references to an existing aggregate definition. To execute this command the current user must be the owner of the aggregate.
" {} "Synopsis" {bold} "
DROP AGGREGATE name type
" {} "Usage" {bold} "
To remove the myavg aggregate for type int4:
DROP AGGREGATE myavg int4;
" {} "Notes" {bold} "
The DROP AGGREGATE statement is a Postgres language extension.
Refer to the CREATE AGGREGATE statement to create aggregate functions. "

14
src/bin/pgaccess/lib/help/drop_database.hlp Normal file
View File

@ -0,0 +1,14 @@
.pgaw:Help.f.t insert end "DROP DATABASE" {bold} " removes the catalog entries for an existing database and deletes the directory containing the data. It can only be executed by the database administrator (See the \
CREATE DATABASE command for details).
" {} "Synopsis" {bold} "
DROP DATABASE name
" {} "Notes" {bold} "
DROP DATABASE statement is a Postgres language extension.
Tip: This query cannot be executed while connected to the target database. It is usually preferable to use the destroydb script instead.
Refer to the CREATE DATABASE statement for information on how to create a database. "

22
src/bin/pgaccess/lib/help/drop_function.hlp Normal file
View File

@ -0,0 +1,22 @@
.pgaw:Help.f.t insert end \
"DROP FUNCTION" {bold} " will remove references to an existing C function. To execute this command the user must be the owner of the function. The input argument types to the function must be specified, as only the function with the given name and argument types will be removed.
" {} "Synopsis" {bold} "
DROP FUNCTION name ( \[ type \[, ...\] \] )
" {code} "
Inputs
" {} "name" {italic} "
The name of an existing function.
" {} "type" {italic} "
The type of function parameters.
Outputs
" {} "DROP" {code} "
Message returned if the command completes successfully.
WARN RemoveFunction: Function \"name\" (\"types\") does not exist
This message is given if the function specified does not exist in the current database."

17
src/bin/pgaccess/lib/help/drop_index.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP INDEX" {bold} " drops an existing index from the database system. To execute this command you must be the owner of the index.
" {} "Synopsis" {bold} "
DROP INDEX index_name
" {code} "Usage" {bold} "
This command will remove the title_idx index:
" {} "
DROP INDEX title_idx;
" {code} "Notes" {bold} "
DROP INDEX is a Postgres language extension.
Refer to the CREATE INDEX statement for information on how to create indexes. "

17
src/bin/pgaccess/lib/help/drop_language.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP LANGUAGE" {bold} " will remove the definition of the previously registered procedural language having the name 'langname'.
" {} "Synopsis" {bold} "
DROP PROCEDURAL LANGUAGE 'langname'
" {code} "Usage" {bold} "
This command removes the PL/Sample language:
" {} "
DROP PROCEDURAL LANGUAGE 'plsample'
" {code} "Notes" {bold} "
The DROP PROCEDURAL LANGUAGE statement is a Postgres language extension.
Refer to CREATE PROCEDURAL LANGUAGE for information on how to create procedural languages. "

32
src/bin/pgaccess/lib/help/drop_operator.hlp Normal file
View File

@ -0,0 +1,32 @@
.pgaw:Help.f.t insert end "DROP OPERATOR" {bold} " The DROP OPERATOR statement drops an existing operator from the database. To execute this command you must be the owner of the operator. \
The left or right type of a left or right unary operator, respectively, may be specified as NONE.
" {} "Synopsis" {bold} "
" {} "
DROP OPERATOR id ( type | NONE \[,...\] )
" {code} "Usage" {bold} "
Remove power operator a^n for int4:
" {} "
DROP OPERATOR ^ (int4, int4);
" {code} "
Remove left unary operator !a for booleans:
" {} "
DROP OPERATOR ! (none, bool);
" {code} "
Remove right unary factorial operator a! for int4:
" {} "
DROP OPERATOR ! (int4, none);
" {code} "Notes" {bold} "
The DROP OPERATOR statement is a Postgres language extension.
Refer to CREATE OPERATOR for information on how to create operators.
It is the user's responsibility to remove any access methods and operator classes that rely on the deleted operator.
"

17
src/bin/pgaccess/lib/help/drop_rule.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP RULE" {bold} " drops a rule from the specified Postgres rule system. Postgres will immediately cease enforcing it and will purge its definition from the system catalogs.
" {} "Synopsis" {bold} "
DROP RULE name
" {} "Usage" {bold} "
To drop the rewrite rule newrule:
DROP RULE newrule
" {} "Notes" {bold} "
The DROP RULE statement is a Postgres language extension.
Refer to CREATE RULE for information on how to create rules. "

17
src/bin/pgaccess/lib/help/drop_sequence.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP SEQUENCE" {bold} " removes sequence number generators from the data base. With the current implementation of sequences as special tables it works just like the DROP TABLE statement.
" {} "Synopsis" {bold} "
" {} "
DROP SEQUENCE seqname \[, ...\]
" {code} "Usage" {bold} "
To remove sequence serial from database:
DROP SEQUENCE serial
" {} "Notes" {bold} "
The DROP SEQUENCE statement is a Postgres language extension.
Refer to the CREATE SEQUENCE statement for information on how to create a sequence. "

17
src/bin/pgaccess/lib/help/drop_table.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP TABLE" {bold} " removes tables and views from the database. Only its owner may destroy a table or view. A table may be emptied of rows, but not destroyed, by using DELETE.
If a table being destroyed has secondary indexes on it, they will be removed first. The removal of just a secondary index will not affect the contents of the underlying table.
" {} "Synopsis" {bold} "
" {} "
DROP TABLE table \[, ...\]
" {code} "Usage" {bold} "
To destroy the films and distributors tables:
DROP TABLE films, distributors
" {} "Notes" {bold} "
Refer to CREATE TABLE and ALTER TABLE for information on how to create or modify tables. "

17
src/bin/pgaccess/lib/help/drop_trigger.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP TRIGGER" {bold} " will remove all references to an existing trigger definition. To execute this command the current user must be the owner of the trigger.
" {} "Synopsis" {bold} "
DROP TRIGGER name ON table
" {} "Usage" {bold} "
Destroy the if_dist_exists trigger on table films:
DROP TRIGGER if_dist_exists ON films;
" {} "Notes" {bold} "
DROP TRIGGER is a Postgres language extension.
Refer to CREATE TRIGGER for information on how to create triggers. "

20
src/bin/pgaccess/lib/help/drop_type.hlp Normal file
View File

@ -0,0 +1,20 @@
.pgaw:Help.f.t insert end "DROP TYPE" {bold} " will remove a user type from the system catalogs.
" {} "Synopsis" {bold} "
DROP TYPE typename
" {} "Usage" {bold} "
To remove the box type:
DROP TYPE box
" {} "Notes" {bold} "
DROP TYPE statement is a Postgres language extension.
Refer to CREATE TYPE for inforamation on how to create types.
It is the user's responsibility to remove any operators, functions, aggregates, access methods, subtypes, and classes that use a deleted type.
"

19
src/bin/pgaccess/lib/help/drop_user.hlp Normal file
View File

@ -0,0 +1,19 @@
.pgaw:Help.f.t insert end "DROP USER" {bold} " removes the specified user from the database, along with any databases owned by the user. It does not remove tables, views, or triggers owned by the named user in databases \
not owned by the user. This statement can be used in place of the destroyuser script, regardless of how the user was created.
" {} "Synopsis" {bold} "
DROP USER username
" {} "Usage" {bold} "
To drop a user account:
DROP USER Jonathan;
" {} "Notes" {bold} "
DROP USER is a Postgres language extension.
Refer to CREATE USER and ALTER USER for information on how to create or modify user accounts.
"

17
src/bin/pgaccess/lib/help/drop_view.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "DROP VIEW" {bold} " drops an existing view from the database. To execute this command you must be the owner of the view.
" {} "Synopsis" {bold} "
DROP VIEW view
" {} "Usage" {bold} "
This command will remove the view called kinds:
DROP VIEW kinds;
" {} "Notes" {bold} "
The Postgres DROP TABLE statement also drops views.
Refer to CREATE VIEW for information on how to create views. "

23
src/bin/pgaccess/lib/help/explain.hlp Normal file
View File

@ -0,0 +1,23 @@
.pgaw:Help.f.t insert end "EXPLAIN" {bold} " This command outputs details about the supplied query. The default output is the computed query cost. The cost value is only meaningful to the optimizer in comparing various query plans. \
VERBOSE displays the full query plan and cost to your screen, and pretty-prints the plan to the postmaster log file.
" {} "Synopsis" {bold} "
" {} "
EXPLAIN \[ VERBOSE \] query
" {code} "Usage" {bold} "
To show a query plan for a simple query:
" {} "
postgres=> explain select * from foo;
NOTICE: QUERY PLAN:
Seq Scan on foo (cost=0.00 rows=0 width=4)
EXPLAIN
" {code} "Notes" {bold} "
There is only sparse documentation on the optimizer's use of cost information in Postgres. General information on cost estimation for query optimization can be found in database textbooks.
Refer to the Programmer's Guide in the chapters on indexes and the genetic query optimizer for more \
information."

62
src/bin/pgaccess/lib/help/fetch.hlp Normal file
View File

@ -0,0 +1,62 @@
.pgaw:Help.f.t insert end "FETCH" {bold} " FETCH allows a user to retrieve rows using a cursor. The number of rows retrieved is specified by #. If the number of rows remaining in the cursor is less than #, then only those available are \
fetched. Substituting the keyword ALL in place of a number will cause all remaining rows in the cursor to be retrieved. Instances may be fetched in both FORWARD and BACKWARD \
directions. The default direction is FORWARD.
Tip: Negative numbers are now allowed to be specified for the row count. A negative number is equivalent to reversing the sense of the FORWARD and BACKWARD \
keywords. For example, FORWARD -1 is the same as BACKWARD 1.
Note that the FORWARD and BACKWARD keywords are Postgres extensions. The SQL92 syntax is also supported, specified in the second form of the command. See below for details on \
compatibility issues.
Once all rows are fetched, every other fetch access returns no rows.
Updating data in a cursor is not supported by Postgres, because mapping cursor updates back to base tables is not generally possible, as is also the case with VIEW updates. Consequently, \
users must issue explicit UPDATE commands to replace data.
Cursors may only be used inside of transactions because the data that they store spans multiple user queries.
" {} "Synopsis" {bold} "
" {} "
FETCH \[ selector \] \[ count \]
\{ IN | FROM \} cursor
FETCH \[ RELATIVE \] \[ \{ \[ # | ALL | NEXT | PRIOR \] \} \]
FROM \] cursor
" {code} "Usage" {bold} "
" {} "
--set up and use a cursor:
--
BEGIN WORK;
DECLARE liahona CURSOR
FOR SELECT * FROM films;
--Fetch first 5 rows in the cursor liahona:
--
FETCH FORWARD 5 IN liahona;
code |title |did| date_prod|kind |len
-----+-----------------------+---+----------+----------+------
BL101|The Third Man |101|1949-12-23|Drama | 01:44
BL102|The African Queen |101|1951-08-11|Romantic | 01:43
JL201|Une Femme est une Femme|102|1961-03-12|Romantic | 01:25
P_301|Vertigo |103|1958-11-14|Action | 02:08
P_302|Becket |103|1964-02-03|Drama | 02:28
--Fetch previous row:
--
FETCH BACKWARD 1 IN liahona;
code |title |did| date_prod|kind |len
-----+-----------------------+---+----------+----------+------
P_301|Vertigo |103|1958-11-14|Action | 02:08
-- close the cursor and commit work:
--
CLOSE liahona;
COMMIT WORK;
" {code} "Notes" {bold} "
Refer to MOVE statements to change cursor position. Refer to DECLARE statements to declare a cursor. Refer to BEGIN WORK, COMMIT WORK, ROLLBACK WORK statements for \
further information about transactions."

27
src/bin/pgaccess/lib/help/form_design.hlp Normal file
View File

@ -0,0 +1,27 @@
.pgaw:Help.f.t insert end "Form designing" {title} "
For the moment, it has only some basic widgets : labels, entries, buttons , listboxes\
, checkboxes and radiobuttons. Also there is a pseudo query widget that allows you\
to have access to a query results.
How do you generate widgets :
-select a widget from the toolbox by clicking the appropriate icon
-move to the canvas , point with the mouse at the desired location and click the mouse button to begin
-keeping the mouse-button pressed move the mouse in order to draw a rectangle that will hold the widget
-release the mouse-button
In the rectangle that you have designed it will appear the selected object. Move now to the attribute window to change some of its properties.
Renaming, resizing items are possible (for the moment) only by modifying appropriate parameters in attribute window. You must press Enter in the edit field after changing a dimension in order to be accepted. You can also move items by dragging them or delete them by pressing Del key after selecting them.
In attribute window, there are some fields named Command and Variable. The field Command have meaning only for Button or checkboxes widgets and holds the command that will be invoked when the button is pressed. Also, there is a \"autoload\" style script for the form that will be executed when form will bne opened.
The field Variable have meaning only for Buttons, EditField , Label widgets , checkboxes and radiobuttons and it is the name of the global variable that will hold the value for that widget. For checkboxes the values are t and f (from true and false) in order to simplify binding to logical data fields.
For radiobuttons, it is usual to assign the same variable to the same radiobuttons within the same group. That variable will contain the value field from the radiobutton that has been pressed. Let's presume that you have entered 3 radiobuttons with values red, green and blue, all of them having the same variable named color. If you will press them, they will assign their names to global variable.
In order to make a simple test, put an entry field and set it's variable to v1 and a button who's command is \"set v1 whisky\". Press the button \"Test form\" and click on the button. In that entry should appear whisky.
Another test is defining in Script module a script called \"My first script\" having the following commands:
" {} "tk_messageBox -title Warning -message \"This is my first message!\" " {code} "
and then define a button with the command is Scripts::execute \"My first script\". "

19
src/bin/pgaccess/lib/help/forms.hlp Normal file
View File

@ -0,0 +1,19 @@
.pgaw:Help.f.t insert end "Forms" {title} "
Forms" {bold} " tab is used to inspect, create and design\
database stored forms that can be later executed.
Forms are actually Tcl/Tk code stored in the opened database in a special table called \"pga_forms\" \
and they can be executed by selecting it and pressing the \"Open\" button.
The design module will allow you do define the graphical layout of the form and\
to bind Tcl/Tk code to different widgets. You will really need to know Tcl/Tk in\
order to be able to write PgAccess forms.
Due to internal limits of PostgreSQL that cannot store more than 8Kb per record\
and taking into account that pga_forms store one form per record it's possible that\
too complicated forms cannot be stored into the table. Too complicated code in\
forms could be stored in scripts instead thought scripts also are limited to the\
8 Kb size.
See also " {} "form designing" {link form_design}

32
src/bin/pgaccess/lib/help/functions.hlp Normal file
View File

@ -0,0 +1,32 @@
.pgaw:Help.f.t insert end "Functions" {title} "
The Functions tab is used to inspect the user defined functions in the\
database, to define new functions and to alter the existing ones.
Press the \"New\" button to define a new function. You should enter the\
function name, the function parameters (if any) separated by comma. \
If function returns a value, you should specify the " {} \
"PostgreSQL data type" {link data_types} " that function will return.
You must also specify the language that will be used to parse the defined\
function. You could specify SQL, plpgsql, pgtcl or C. Then you should enter the\
function body. Press \"Save\" button in order to save it
" {} "Example:" {italic} "
We have a table called \"products\" that is indexed on \"id\" (int4) field and\
contains the float8 field \"price\". We will define a new function \"get_product_price\"\
that will return the product price for a given id.
You should enter " {} "get_product_price" {code} " as the function name, " {} \
"int4" {code} " in parameters entry, " {} "float8" {code} " for returns, " {} \
"SQL" {code} " for the language. Then go to the function body definition and type:" {} "
SELECT price FROM products where id = \$1" {code} "
To delete a function, select it from the list box and use the menu command\
Object/Delete.
For more information see SQL commands " {} "CREATE FUNCTION" {link create_function} " and " {} \
"DROP FUNCTION" {link drop_function}

73
src/bin/pgaccess/lib/help/geomfunc.hlp Normal file
View File

@ -0,0 +1,73 @@
.pgaw:Help.f.t insert end \
"Geometric functions\n\n" {title} \
"area(box) " {bold} "
Returns: float8
area of box
" {} "area(circle) " {bold} "
Returns: float8
area of circle
" {} "box(box,box) " {bold} "
Returns: box
boxes to intersection box
" {} "center(box) " {bold} "
Returns: point
center of object
" {} "center(circle) " {bold} "
Returns: point
center of object
" {} "diameter(circle) " {bold} "
Returns: float8
diameter of circle
" {} "height(box) " {bold} "
Returns: float8
vertical size of box
" {} "isclosed(path) " {bold} "
Returns: bool
a closed path?
" {} "isopen(path) " {bold} "
Returns: bool
an open path?
" {} "length(lseg) " {bold} "
Returns: float8
length of line segment
" {} "length(path) " {bold} "
Returns: float8
length of path
" {} "pclose(path) " {bold} "
Returns: path
convert path to closed
" {} "point(lseg,lseg) " {bold} "
Returns: point
intersection
" {} "points(path) " {bold} "
Returns: int4
number of points
" {} "popen(path) " {bold} "
Returns: path
convert path to open
" {} "radius(circle) " {bold} "
Returns: float8
radius of circle
" {} "width(box) " {bold} "
Returns: float8
horizontal size
" {} \
"PostgreSQL functions\n" {link pgfunctions} \
"Next - IP V4 functions" {link ipv4func}

52
src/bin/pgaccess/lib/help/grant.hlp Normal file
View File

@ -0,0 +1,52 @@
.pgaw:Help.f.t insert end "GRANT" {bold} " GRANT allows the creator of an object to give specific permissions to all users (PUBLIC) or to a certain user or group. Users other than the creator don't have any access permission unless \
the creator GRANTs permissions, after the object is created.
Once a user has a privilege on an object, he is enabled to exercise that privilege. There is no need to GRANT privileges to the creator of an object, the creator automatically holds ALL \
privileges, and can also drop the object.
" {} "Synopsis" {bold} "
" {} "
GRANT privilege \[, ...\]
ON object \[, ...\]
TO \{ PUBLIC | GROUP group | username \}
" {code} "Usage" {bold} "
" {} "
-- grant insert privilege to all users on table films:
--
GRANT INSERT ON films TO PUBLIC;
-- grant all privileges to user manuel on view kinds:
--
GRANT ALL ON kinds TO manuel;
" {code} "Notes" {bold} "
Use the psql \\z command for further information about permissions on existing objects:
" {} "
Database = lusitania
+------------------+------------------------------------------------+
| Relation | Grant/Revoke Permissions |
+------------------+------------------------------------------------+
| mytable | \{\"=rw\",\"miriam=arwR\",\"group todos=rw\"\} |
+------------------+------------------------------------------------+
Legend:
uname=arwR -- privileges granted to a user
group gname=arwR -- privileges granted to a GROUP
=arwR -- privileges granted to PUBLIC
r -- SELECT
w -- UPDATE/DELETE
a -- INSERT
R -- RULE
arwR -- ALL
" {code} "Tip" {bold} "
Tip: Currently, to create a GROUP you have to insert data manually into table pg_group as:
INSERT INTO pg_group VALUES ('todos');
CREATE USER miriam IN GROUP todos;
Refer to REVOKE statements to revoke access privileges. "

43
src/bin/pgaccess/lib/help/history.hlp Normal file
View File

@ -0,0 +1,43 @@
.pgaw:Help.f.t insert end \
"PostgreSQL history\n\n" {title} \
"The Berkeley Postgres project\n" {bold} \
"Implementation of the Postgres DBMS began in 1986. The initial concepts for the system were presented in The Design of Postgres and the definition of the initial data model appeared in The Postgres Data Model. The design of the rule system at that time was described in The Design of the Postgres Rules System. The rationale and architecture of the storage manager were detailed in The Postgres Storage System.
Postgres has undergone several major releases since then. The first 'demoware' system became operational in 1987 and was shown at the 1988 ACM-SIGMOD Conference. We released Version 1, described in The Implementation of Postgres, to a few external users in June 1989. In response to a critique of the first rule system (A Commentary on the Postgres Rules System), the rule system was redesigned (On Rules, Procedures, Caching and Views in Database Systems) and Version 2 was released in June 1990 with the new rule system. Version 3 appeared in 1991 and added support for multiple storage managers, an improved query executor, and a rewritten rewrite rule system. For the most part, releases since then have focused on portability and reliability.
Postgres has been used to implement many different research and production applications. These include: a financial data analysis system, a jet engine performance monitoring package, an asteroid tracking database, a medical information database, and several geographic information systems. Postgres has also been used as an educational tool at several universities. Finally, Illustra Information Technologies (since merged into Informix) picked up the code and commercialized it. Postgres became the primary data manager for the Sequoia 2000 scientific computing project in late 1992. Furthermore, the size of the external user community nearly doubled during 1993. It became increasingly obvious that maintenance of the prototype code and support was taking up large amounts of time that should have been devoted to database research. In an effort to reduce this support burden, the project officially ended with Version 4.2.
" {} \
"Postgres95\n" {bold} \
"In 1994, Andrew Yu and Jolly Chen added a SQL language interpreter to Postgres, and the code was subsequently released to the Web to find its own way in the world. Postgres95 was a public-domain, open source descendant of this original Berkeley code.
Postgres95 is a derivative of the last official release of Postgres (version 4.2). The code is now completely ANSI C and the code size has been trimmed by 25%. There are a lot of internal changes that improve performance and code maintainability. Postgres95 v1.0.x runs about 30-50% faster on the Wisconsin Benchmark compared to v4.2. Apart from bug fixes, these are the major enhancements:
The query language Postquel has been replaced with SQL (implemented in the server). We do not yet support subqueries (which can be imitated with user defined SQL functions). Aggregates have been re-implemented. We also added support for ``GROUP BY''. The libpq interface is still available for C programs.
In addition to the monitor program, we provide a new program (psql) which supports GNU readline.
We added a new front-end library, libpgtcl, that supports Tcl-based clients. A sample shell, pgtclsh, provides new Tcl commands to interface tcl programs with the Postgres95 backend.
The large object interface has been overhauled. We kept Inversion large objects as the only mechanism for storing large objects. (This is not to be confused with the Inversion file system which has been removed.)
The instance-level rule system has been removed. Rules are still available as rewrite rules.
A short tutorial introducing regular SQL features as well as those of ours is distributed with the source code.
GNU make (instead of BSD make) is used for the build. Also, Postgres95 can be compiled with an unpatched gcc (data alignment of doubles has been fixed).
" {} \
"PostgreSQL\n" {bold} \
"By 1996, it became clear that the name \"Postgres95\" would not stand the test of time. A new name, PostgreSQL, was chosen to reflect the relationship between original Postgres and the more recent versions with SQL capability. At the same time, the version numbering was reset to start at 6.0, putting the numbers back into the sequence originally begun by the Postgres Project.
The emphasis on development for the v1.0.x releases of Postgres95 was on stabilizing the backend code. With the v6.x series of PostgreSQL, the emphasis has shifted from identifying and understanding existing problems in the backend to augmenting features and capabilities, although work continues in all areas.
Major enhancements include:
- Important backend features, including subselects, defaults, constraints, and triggers, have been implemented.
- Additional SQL92-compliant language features have been added, including primary keys, quoted identifiers, literal string type coersion, type casting, and binary and hexadecimal integer input.
- Built-in types have been improved, including new wide-range date/time types and additional geometric type support.
- Overall backend code speed has been increased by approximately 20-40%, and backend startup time has decreased 80% since v6.0 was released."

19
src/bin/pgaccess/lib/help/index.hlp Normal file
View File

@ -0,0 +1,19 @@
.pgaw:Help.f.t insert end \
"PgAccess help index" {title} \
"
Topics available:
" {} \
" Tables\n" {link tables} \
" Queries\n" {link queries} \
" Views\n" {link views} \
" Sequences\n" {link sequences} \
" Functions\n" {link functions} \
" Reports\n" {link reports} \
" Forms\n" {link forms} \
" Scripts\n" {link scripts} \
" Users\n" {link users} \
" Schema\n\n" {link schema} \
" PostgreSQL\n" {link postgresql} \
" The author of PgAccess\n" {link author}

49
src/bin/pgaccess/lib/help/inheritance.hlp Normal file
View File

@ -0,0 +1,49 @@
.pgaw:Help.f.t insert end \
"Inheritance" {title} "
Let's create two classes. The capitals class contains state capitals which are also cities. Naturally, the capitals class should inherit from cities.
" {} "CREATE TABLE cities (
name text,
population float,
altitude int -- (in ft)
);
CREATE TABLE capitals (
state char2
) INHERITS (cities);
" {code} "
In this case, an instance of capitals inherits all attributes (name, population, and altitude) from its parent, cities. The type of the attribute name is text, a native Postgres type for variable length ASCII strings. The type of the attribute population is float, a native Postgres type for double precision floating point numbers. State capitals have an extra attribute, state, that shows their state. In Postgres, a class can inherit from zero or more other classes, and a query can reference either all instances of a class or all instances of a class plus all of its descendants.
" {} "Note" {italic} ": The inheritance hierarchy is a actually a directed acyclic graph.
For example, the following query finds all the cities that are situated at an attitude of 500ft or higher:
" {} "SELECT name, altitude FROM cities WHERE altitude > 500;
+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
" {code} "
On the other hand, to find the names of all cities, including state capitals, that are located at an altitude over 500ft, the query is:
" {} "SELECT c.name, c.altitude FROM cities* c WHERE c.altitude > 500;
" {code} "which returns:" {} "
+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
|Madison | 845 |
+----------+----------+
" {code} "
Here the \"*\" after cities indicates that the query should be run over cities and all classes below cities in the inheritance hierarchy. Many of the commands that we have already discussed -- select, update and delete -- support this \"*\" notation, as do others, like alter.
" {}

54
src/bin/pgaccess/lib/help/insert.hlp Normal file
View File

@ -0,0 +1,54 @@
.pgaw:Help.f.t insert end "INSERT" {bold} " allows one to insert new rows into a table. One can insert a single row at time or several rows as a result of a query. The columns in the target list may be listed in any order. In every \
column not present in the target list will be inserted the default value, if column has not a declared default value it will be assumed as NULL. If the expression for each column is not of the \
correct data type, automatic type coercion will be attempted.
" {} "Synopsis" {bold} "
" {} "
INSERT INTO table \[ ( column \[, ...\] ) \]
\{ VALUES ( expression \[, ...\] ) | SELECT query \}
" {code} "Usage" {bold} "
" {} "
--Insert a single row into table films;
--(in the second example the column date_prod is omitted
--therefore will be stored in it a default value of NULL):
--
INSERT INTO films VALUES
('UA502','Bananas',105,'1971-07-13','Comedy',INTERVAL '82 minute');
INSERT INTO films (code, title, did, date_prod, kind)
VALUES ('T_601', 'Yojimbo', 106, DATE '1961-06-16', 'Drama');
--Insert a single row into table distributors, note that
--only column \"name\" is specified, to the non specified
--column \"did\" will be assigned its default value:
--
INSERT INTO distributors (name) VALUES ('British Lion');
--Insert several rows into table films from table tmp:
--
INSERT INTO films
SELECT * FROM tmp;
--Insert into arrays:
--Create an empty 3x3 gameboard for noughts-and-crosses
--(all of these queries create the same board attribute)
--(Refer to the PostgreSQL User's Guide for further
--information about arrays).
INSERT INTO tictactoe (game, board\[1:3\]\[1:3\])
VALUES (1,'\{\{\"\",\"\",\"\"\},\{\},\{\"\",\"\"\}\}');
INSERT INTO tictactoe (game, board\[3\]\[3\])
VALUES (2,'\{\}');
INSERT INTO tictactoe (game, board)
VALUES (3,'\{\{,,\},\{,,\},\{,,\}\}');
" {code} "Compatibility" {bold} "
SQL92
The INSERT statement is fully compatible with SQL92. Possible limitations in features of the query clause are documented for the SELECT statement.
"

28
src/bin/pgaccess/lib/help/ipv4func.hlp Normal file
View File

@ -0,0 +1,28 @@
.pgaw:Help.f.t insert end \
"IP V4 functions\n\n" {title} \
"broadcast(cidr)" {bold} "
Returns: text
construct broadcast address as text
" {} "broadcast(inet) " {bold} "
Returns: text
construct broadcast address as text
" {} "host(inet) " {bold} "
Returns: text
extract host address as text
" {} "masklen(cidr) " {bold} "
Returns: int4
calculate netmask length
" {} "masklen(inet) " {bold} "
Returns: int4
calculate netmask length
" {} "netmask(inet) " {bold} "
Returns: text
construct netmask as text
" {} \
"PostgreSQL functions\n" {link pgfunctions}

24
src/bin/pgaccess/lib/help/isolation.hlp Normal file
View File

@ -0,0 +1,24 @@
.pgaw:Help.f.t insert end \
"Isolation levels" {title} "
" {} "Read Committed Isolation Level" {bold} "
Read Committed is the default isolation level in Postgres. When a transaction runs on this isolation level, a query sees only data committed before the query began and never sees either dirty data or concurrent transaction changes committed during query execution.
If a row returned by a query while executing an UPDATE statement (or DELETE or SELECT FOR UPDATE) is being updated by a concurrent uncommitted transaction then the second transaction that tries to update this row will wait for the other transaction to commit or rollback. In the case of rollback, the waiting transaction can proceed to change the row. In the case of commit (and if the row still exists; i.e. was not deleted by the other transaction), the query will be re-executed for this row to check that new row version satisfies query search condition. If the new row version satisfies the query search condition then row will be updated (or deleted or marked for update).
Note that the results of execution of SELECT or INSERT (with a query) statements will not be affected by concurrent transactions.
" {} "Serializable Isolation Level" {bold} "
Serializable provides the highest transaction isolation. When a transaction is on the serializable level, a query sees only data committed before the transaction began and never see either dirty data or concurrent transaction changes committed during transaction execution. So, this level emulates serial transaction execution, as if transactions would be executed one after another, serially, rather than concurrently.
If a row returned by query while executing a UPDATE (or DELETE or SELECT FOR UPDATE) statement is being updated by a concurrent uncommitted transaction then the second transaction that tries to update this row will wait for the other transaction to commit or rollback. In the case of rollback, the waiting transaction can proceed to change the row. In the case of a concurrent transaction commit, a serializable transaction will be rolled back with the message
" {} "ERROR: Can't serialize access due to concurrent update" {code} "
because a serializable transaction cannot modify rows changed by other transactions after the serializable transaction began.
" {} "Note" {italic} ": Note that results of execution of SELECT or INSERT (with a query) will not be affected by concurrent transactions.
"

85
src/bin/pgaccess/lib/help/keywords.hlp Normal file
View File

@ -0,0 +1,85 @@
.pgaw:Help.f.t insert end \
"PostgreSQL reserved key words\n\n" {title} \
"The following are Postgres reserved words which are also SQL92 or SQL3 reserved words: " {} \
"
ADD ALL ALTER AND ANY AS ASC
BEGIN BETWEEN BOTH BY
CASCADE CAST CHAR CHARACTER CHECK CLOSE
COLLATE COLUMN COMMIT CONSTRAINT
CREATE CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER CURSOR
DECIMAL DECLARE DEFAULT DELETE DESC DISTINCT DROP
EXECUTE EXISTS EXTRACT
FETCH FLOAT FOR FROM FULL
GRANT
HAVING
IN INNER INSERT INTERVAL INTO IS
JOIN
LEADING LEFT LIKE LOCAL
NAMES NATIONAL NATURAL NCHAR NO NOT NULL NUMERIC
ON OR OUTER
PARTIAL PRIMARY PRIVILEGES PROCEDURE PUBLIC
REFERENCES REVOKE RIGHT ROLLBACK
SELECT SET SUBSTRING
TO TRAILING TRIM
UNION UNIQUE UPDATE USER USING
VALUES VARCHAR VARYING VIEW
WHERE WITH WORK
" {code} \
"The following are Postgres reserved words which are neither SQL92 nor SQL3 reserved words. These are allowed to be present as column labels, but not as identifiers: " {} \
"
ABORT ANALYZE
BINARY
CLUSTER CONSTRAINT COPY
DO
EXPLAIN EXTEND
LISTEN LOAD LOCK
MOVE
NEW NONE NOTIFY
RESET
SETOF SHOW
UNLISTEN UNTIL
VACUUM VERBOSE
" {code} \
"The following are Postgres reserved words which are also SQL92 or SQL3 reserved words, and which are allowed to be present as column labels, but not as identifiers: " {} \
"
CASE COALESCE CROSS CURRENT
ELSE END
FALSE FOREIGN
GLOBAL GROUP
LOCAL
NULLIF
ORDER
POSITION PRECISION
TABLE THEN TRANSACTION TRUE
WHEN
" {code} \
"The following are either SQL92 or SQL3 reserved key words which are not key words in Postgres. These have no proscribed usage in Postgres at the time of writing (v6.5) but may become reserved key words in the future: " {} \
"
Note: Some of these key words represent functions in SQL92. These functions are defined in Postgres, but the parser does not consider the names to be key words and they are allowed in other contexts.
ALLOCATE ARE ASSERTION AT AUTHORIZATION AVG
BIT BIT_LENGTH
CASCADED CATALOG COLLATION CONNECT CONNECTION
CONSTRAINTS CONTINUE CONVERT CORRESPONDING COUNT
DATE DEALLOCATE DEC DESCRIBE DESCRIPTOR DIAGNOSTICS DISCONNECT DOMAIN
END-EXEC ESCAPE EXCEPT EXCEPTION EXEC EXTERNAL
FIRST FOUND
GET GO GOTO
IDENTITY IMMEDIATE INDICATOR INITIALLY INPUT INTERSECT ISOLATION
LAST LEVEL LOWER
MAX MIN MODULE
OCTET_LENGTH OPEN OUTPUT OVERLAPS
PREPARE PRESERVE
RESTRICT ROWS
SCHEMA SECTION SESSION SESSION_USER SIZE SOME
SQL SQLCODE SQLERROR SQLSTATE SUM SYSTEM_USER
TEMPORARY TRANSLATE TRANSLATION
UNKNOWN UPPER USAGE
VALUE
WHENEVER WRITE
" {code}

34
src/bin/pgaccess/lib/help/listen.hlp Normal file
View File

@ -0,0 +1,34 @@
.pgaw:Help.f.t insert end "LISTEN" {bold} " registers the current Postgres backend as a listener on the notify condition notifyname. \
Whenever the command NOTIFY notifyname is invoked, either by this backend or another one connected to the same database, all the backends currently listening on that notify condition are \
notified, and each will in turn notify its connected frontend application. See the discussion of NOTIFY for more information. \
A backend can be deregistered for a given notify condition with the UNLISTEN command. Also, a backend's listen registrations are automatically cleared when the backend process exits. \
The method a frontend application must use to detect notify events depends on which Postgres application programming interface it uses. With the basic libpq library, the application issues \
LISTEN as an ordinary SQL command, and then must periodically call the routine PQnotifies to find out whether any notify events have been received. Other interfaces such as libpgtcl provide \
higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the library \
you are using for more details.
The reference page for NOTIFY contains a more extensive discussion of the use of LISTEN and NOTIFY.
" {} "Synopsis" {bold} "
LISTEN notifyname
" {} "Usage" {bold} "
" {} "
-- Configure and execute a listen/notify sequence from psql
postgres=> listen virtual;
LISTEN
postgres=> notify virtual;
NOTIFY
ASYNC NOTIFY of 'virtual' from backend pid '11239' received
" {code} "Notes" {bold} "
notifyname can be any string valid as a name; it need not correspond to the name of any actual table. If notifyname is enclosed in double-quotes, it need not even be a syntactically valid name, \
but can be any string up to 31 characters long.
In some previous releases of Postgres, notifyname had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no \
longer required. "

27
src/bin/pgaccess/lib/help/load.hlp Normal file
View File

@ -0,0 +1,27 @@
.pgaw:Help.f.t insert end "LOAD" {bold} " Loads an object (or \".o\") file into the Postgres backend address space. Once a file is loaded, all functions in that file can be accessed. This function is used in support of user-defined types and \
functions.
If a file is not loaded using LOAD, the file will be loaded automatically the first time the function is called by Postgres. LOAD can also be used to reload an object file if it has been edited and \
recompiled. Only objects created from C language files are supported at this time.
" {} "Synopsis" {bold} "
LOAD 'filename'
" {} "Usage" {bold} "
--Load the file /usr/postgres/demo/circle.o
--
LOAD '/usr/postgres/demo/circle.o'
" {} "Notes" {bold} "
Functions in loaded object files should not call functions in other object files loaded through the LOAD command. For example, all functions in file A should call each other, functions in the \
standard or math libraries, or in Postgres itself. They should not call functions defined in a different loaded file B. This is because if B is reloaded, the Postgres loader is not able to relocate the \
calls from the functions in A into the new address space of B. If B is not reloaded, however, there will not be a problem.
Object files must be compiled to contain position independent code. For example, on DECstations you must use /bin/cc with the -G 0 option when compiling object files to be loaded. \
Note that if you are porting Postgres to a new platform, LOAD will have to work in order to support ADTs.
"

49
src/bin/pgaccess/lib/help/lock.hlp Normal file
View File

@ -0,0 +1,49 @@
.pgaw:Help.f.t insert end "LOCK" {bold} " Postgres always uses the least restrictive lock mode whenever possible. LOCK TABLE provided for cases when you might need more restrictive locking.
For example, an application runs a transaction at READ COMMITTED isolation level and needs to ensure the existance of data in a table for the duration of the transaction. To achieve this you \
could use SHARE lock mode over the table before querying. This will protect data from concurrent changes and provide any further read operations over the table with data in their actual current \
state, because SHARE lock mode conflicts with any ROW EXCLUSIVE one acquired by writers, and your LOCK TABLE table IN SHARE MODE statement will wait until any concurrent \
write operations commit or rollback.
" {} "Synopsis" {bold} "
" {} "
LOCK \[ TABLE \] table
LOCK \[ TABLE \] table IN \[ ROW | ACCESS \] \{ SHARE | EXCLUSIVE \} MODE
LOCK \[ TABLE \] table IN SHARE ROW EXCLUSIVE MODE
" {code} "Usage" {bold} "
--
-- SHARE lock primary key table when going to perform
-- insert into foreign key table.
--
" {} " BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
--
-- Do ROLLBACK if record was not returned
--
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
--
-- SHARE ROW EXCLUSIVE lock primary key table when going to perform
-- delete operation.
--
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
(SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
" {code} "Notes" {bold} "
LOCK is a Postgres language extension.
Except for ACCESS SHARE/EXCLUSIVE lock modes, all other Postgres lock modes and the LOCK TABLE syntax are compatible with those present in Oracle.
LOCK works only inside transactions. "

34
src/bin/pgaccess/lib/help/mathfunc.hlp Normal file
View File

@ -0,0 +1,34 @@
.pgaw:Help.f.t insert end \
"Mathematical functions\n\n" {title} \
"dexp(float8)" {bold} \
"
Returns: float8
raise e to the specified exponent
" {} \
"dpow(float8,float8)" {bold} \
"
Returns: float8
raise a number to the specified exponent
" {} \
"float(int)" {bold} \
"
Returns: float8
convert integer to floating point
" {} \
"float4(int)" {bold} \
"
Returns: float4
convert integer to floating point
" {} \
"integer(float)" {bold} \
"
Returns: int
convert floating point to integer
" {} \
"PostgreSQL functions\n" {link pgfunctions} \
"Next - string functions" {link stringfunc}

43
src/bin/pgaccess/lib/help/move.hlp Normal file
View File

@ -0,0 +1,43 @@
.pgaw:Help.f.t insert end "MOVE" {bold} "allows a user to move cursor position a specified number of rows. MOVE works like the FETCH command, but only positions the cursor and does not return rows.
Refer to the FETCH command for details on syntax and usage.
" {} "Synopsis" {bold} "
" {} "
MOVE \[ selector \] \[ count \]
\{ IN | FROM \} cursor
FETCH \[ RELATIVE \] \[ \{ \[ # | ALL | NEXT | PRIOR \] \} \] FROM \] cursor
" {code} "Usage" {bold} "
--set up and use a cursor:
--
" {} " BEGIN WORK;
DECLARE liahona CURSOR FOR SELECT * FROM films;
--Skip first 5 rows:
--
MOVE FORWARD 5 IN liahona;
MOVE
--Fetch 6th row in the cursor liahona:
--
FETCH 1 IN liahona;
FETCH
code |title |did| date_prod|kind |len
-----+------+---+----------+----------+------
P_303|48 Hrs|103|1982-10-22|Action | 01:37
(1 row)
-- close the cursor liahona and commit work:
--
CLOSE liahona;
COMMIT WORK;
" {code} "Notes" {bold} "
MOVE is a Postgres language extension.
Refer to FETCH for a description of valid arguments. Refer to DECLARE to declare a cursor. Refer to BEGIN WORK, COMMIT WORK, ROLLBACK WORK statements for further \
information about transactions. "

13
src/bin/pgaccess/lib/help/mvcc.hlp Normal file
View File

@ -0,0 +1,13 @@
.pgaw:Help.f.t insert end \
"Multi-Version Concurrency Control" {title} "
Multi-Version Concurrency Control (MVCC) is an advanced technique for\
improving database performance in a multi-user environment. " {} "Vadim Mikheev" {bold} " provided the implementation for Postgres.
" {} "Introduction" {bold} "
Unlike most other database systems which use locks for concurrency control, Postgres maintains data consistency by using a multiversion model. This means that while querying a database each transaction sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data. This protects the transaction from viewing inconsistent data that could be caused by (other) concurrent transaction updates on the same data rows, providing transaction isolation for each database session.
The main difference between multiversion and lock models is that in MVCC locks acquired for querying (reading) data don't conflict with locks acquired for writing data and so reading never blocks writing and writing never blocks reading.
" {} "Isolation levels" {link isolation}

22
src/bin/pgaccess/lib/help/new_query.hlp Normal file
View File

@ -0,0 +1,22 @@
.pgaw:Help.f.t insert end \
"Creating a new query" {bold} "
Select the \"Queries\" tab from the main window and press\
the \"New\" button.
You will need to enter the query name and the SQL command for the query. If\
you desire, you could use the " {} "visual query designer" {link visual_designer} "
You can design dynamic queries that can include a parameter that will be\
provided later at query execution time by using the \[parameter \"message\"\] function\
as in the following examples :" {} "
select * from people where age <= \[parameter \"Maximum age?\"\]
select * from invoices where received_date = '\[parameter \"Invoice date?\"\]' " {code} "
Before query execution a popup dialog will be displayed in order to get that\
parameter and to substitute it in the query command.
Checking the \"save this query as a view\" checkbox will create a new view from\
the current query.
"

31
src/bin/pgaccess/lib/help/new_table.hlp Normal file
View File

@ -0,0 +1,31 @@
.pgaw:Help.f.t insert end \
"Creating a new table" {bold} "
Select the \"Tables\" tab from the main window and then press then \"New\" button.\
A form will be displayed allowing you to define a new table.
You should enter the table name and then to define the fields.\
At this point you can define also a primary key for that table by checking the \"primary key\" checkbox for the fields that will be included in the primary key. Fields selected for the primary key will be displayed with a * in the K column.\
The \"size\" entry is used in order to specify the dimension for those field types\
that have variable dimensions (varchar, char). Otherwise, it will be disabled.\
The \"default value\" entry can be used in order to specify the field's default\
value that will be assigned if a value is not specified in the insert command.
The \"check\" entry can be used in order to specify a boolean expression using\
tables fields or defined functions that will\
be checked on every insert or update command. The \"constraint\" entry is optional\
and it's just for naming purposes.
" {} "Example:" {italic} "
(price > 0) and (quantity > 0) and valid_product(product_id)
" {code} "
In the above example, price and quantity are fields from the new table and\
valid_product(product_id) is a SQL function that will return the boolean value true\
if the product_id was found in another table \"products\".
In the \"Inherits\" field you can select one or more tables. They will be separated\
with commas. The new table will inherit all the fields from the parent tables.\
Read more " {} "about inheritance here." {link inheritance} "
Select a field from the listbox and use the \"Move up\" and \"Move down\" buttons in order to rearrange the field order. At the end, press the \"Create\" button to define the table.
Read also about " {} "CREATE TABLE" {link create_table} " SQL command."

57
src/bin/pgaccess/lib/help/notify.hlp Normal file
View File

@ -0,0 +1,57 @@
.pgaw:Help.f.t insert end "NOTIFY" {bold} " The NOTIFY command sends a notify event to each frontend application that has previously executed LISTEN notifyname for the specified notify condition in the current database.
The information passed to the frontend for a notify event includes the notify condition name and the notifying backend process's PID. It is up to the database designer to define the condition \
names that will be used in a given database and what each one means.
Commonly, the notify condition name is the same as the name of some table in the database, and the notify event essentially means
\"I changed this table, take a look at it to see what's new\". \
But no such association is enforced by the NOTIFY and LISTEN commands. For example, a database designer could use several different condition names to signal different sorts of changes \
to a single table.
NOTIFY provides a simple form of signal or IPC (interprocess communication) mechanism for a collection of processes accessing the same Postgres database. Higher-level mechanisms can \
be built by using tables in the database to pass additional data (beyond a mere condition name) from notifier to listener(s).
When NOTIFY is used to signal the occurrence of changes to a particular table, a useful programming technique is to put the NOTIFY in a rule that is triggered by table updates. In this way, \
notification happens automatically when the table is changed, and the application programmer can't accidentally forget to do it.
NOTIFY interacts with SQL transactions in some important ways. Firstly, if a NOTIFY is executed inside a transaction, the notify events are not delivered until and unless the transaction is \
committed. This is appropriate, since if the transaction is aborted we would like all the commands within it to have had no effect --- including NOTIFY. But it can be disconcerting if one is \
expecting the notify events to be delivered immediately. Secondly, if a listening backend receives a notify signal while it is within a transaction, the notify event will not be delivered to its \
connected frontend until just after the transaction is completed (either committed or aborted). Again, the reasoning is that if a notify were delivered within a transaction that was later aborted, \
one would want the notification to be undone somehow --- but the backend cannot \"take \
back\" a notify once it has sent it to the frontend. So notify events are only delivered between \
transactions. The upshot of this is that applications using NOTIFY for real-time signaling should try to keep their transactions short.
NOTIFY behaves like Unix signals in one important respect: if the same condition name is signaled multiple times in quick succession, recipients may get only one notify event for several \
executions of NOTIFY. So it is a bad idea to depend on the number of notifies received. Instead, use NOTIFY to wake up applications that need to pay attention to something, and use a \
database object (such as a sequence) to keep track of what happened or how many times it happened.
It is common for a frontend that sends NOTIFY to be listening on the same notify name itself. In that case it will get back a notify event, just like all the other listening frontends. Depending on \
the application logic, this could result in useless work --- for example, re-reading a database table to find the same updates that that frontend just wrote out. In Postgres 6.4 and later, it is \
possible to avoid such extra work by noticing whether the notifying backend process's PID (supplied in the notify event message) is the same as one's own backend's PID (available from \
libpq). When they are the same, the notify event is one's own work bouncing back, and can be ignored. (Despite what was said in the preceding paragraph, this is a safe technique. Postgres \
keeps self-notifies separate from notifies arriving from other backends, so you cannot miss an outside notify by ignoring your own notifies.)
" {} "Synopsis" {bold} "
NOTIFY notifyname
" {} "Usage" {bold} "
-- Configure and execute a listen/notify sequence from psql
" {} " postgres=> listen virtual;
LISTEN
postgres=> notify virtual;
NOTIFY
ASYNC NOTIFY of 'virtual' from backend pid '11239' received
" {code} "Notes" {bold} "
notifyname can be any string valid as a name; it need not correspond to the name of any actual table. If notifyname is enclosed in double-quotes, it need not even be a syntactically valid name, \
but can be any string up to 31 characters long.
In some previous releases of Postgres, notifyname had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no \
longer required.
In Postgres releases prior to 6.4, the backend PID delivered in a notify message was always the PID of the frontend's own backend. So it was not possible to distinguish one's own notifies from \
other clients' notifies in those earlier releases. "

17
src/bin/pgaccess/lib/help/open_query.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end \
"Open a query for vieweing" {bold} "
Select the \"Queries\" tab from the main window and select a query from the list. Press on \
the \"Open\" button.
If the query will return some records (i.e. is not an action query) a query \
viewer will be displayed and the selected rows from the result will be displayed.
You will not be able to specify a sort field or a filter as you can do it in \
table viewer. If you want to specify sort fields, go and edit the query command \
and add there the desired sort order or filter conditions.
Also, you will not be able to change or to add new records.
If the selected query is an \"action query\" (INSERT INTO, DELETE FROM, UPDATE) \
a confirmation for the query execution will be requested.
"

19
src/bin/pgaccess/lib/help/open_table.hlp Normal file
View File

@ -0,0 +1,19 @@
.pgaw:Help.f.t insert end \
"Opening tables for viewing and editing" {bold} "
Select the \"Tables\" tab from the main window ,select a table from the listbox and click with the mouse on the \"Open\" button. A new table viewer window will be opened showing you the records from that table
" {} "Note:" {italic} " Due to the fact that the records being displayed are kept in memory, only the first 200 records from that table will be displayed. The maximum number of records being displayed can be changed in the Database/Preference dialog.
You can sort and filter the records being displayed. Go to the \"Sort field\" entry and type the name of the field. Add the desc (descending) keyword if you want records to be sorted in reverse order. If you want to sort the records based on multiple fields just separate them with commas
" {} "Example:" {italic} "
Sort field: price
Sort field: price desc, customer asc
" {code} "
If you want to select for display just some records frm that table go to the \"Filter conditions\" entry and specify a filter criteria.
" {} "Example:" {italic} "
Filter conditions: (price > 150) and (not sold)
" {code} "
After specifying a sort field or a filter conditions, pres Enter or the \"Reload\" button."

13
src/bin/pgaccess/lib/help/pgfunctions.hlp Normal file
View File

@ -0,0 +1,13 @@
.pgaw:Help.f.t insert end \
"PostgreSQL functions" {title} \
"
Many data types have functions available for conversion to other related types. In addition, there are some type-specific functions. Some functions are also available through operators and may be documented as operators only.
" {} \
"\tSQL functions\n" {link sqlfunc} \
"\tMathematical functions\n" {link mathfunc} \
"\tString functions\n" {link stringfunc} \
"\tDate/Time functions\n" {link datefunc} \
"\tGeometric functions\n" {link geomfunc} \
"\tIP V4 functions" {link ipv4func}

13
src/bin/pgaccess/lib/help/postgresql.hlp Normal file
View File

@ -0,0 +1,13 @@
.pgaw:Help.f.t insert end \
"PostgreSQL" {title} \
"\n\n" {} \
"What is PostgreSQL?\n" {bold} \
" PostgreSQL is a object-relational database management system, originally developed at the University of California at Berkeley. PostgreSQL is based on Postgres release 4.2. The Postgres project, led by Professor Michael Stonebraker, was sponsored by the Defense Advanced Research Projects Agency (DARPA), the Army Research Office (ARO), the National Science Foundation (NSF), and ESL, Inc.\n\n" {} \
" History of PostgreSQL\n" {link history} \
" Copyrights\n" {link copyrights} \
" Y2K statement\n" {link y2k} \
" PostgreSQL reserved key words\n" {link keywords} \
" Data types" {link data_types} " , " {} "Functions\n" {link pgfunctions} \
" Quick guide of PostgreSQL commands\n" {link sql_guide} \
" Inheritance\n" {link inheritance} \
" Multi-Version Concurency Control\n" {link mvcc}

8
src/bin/pgaccess/lib/help/queries.hlp Normal file
View File

@ -0,0 +1,8 @@
.pgaw:Help.f.t insert end \
"Queries" {title} \
"\n\n" {} \
" The following topics are available:\n" {} \
" creating a new query\n" {link new_query} \
" opening a query for viewing\n" {link open_query} \
" visual query designer\n" {link visual_designer}

10
src/bin/pgaccess/lib/help/reports.hlp Normal file
View File

@ -0,0 +1,10 @@
.pgaw:Help.f.t insert end "The Reports module is still in alpha stage.
The module should be able to design and execute a report based on a table\
or from an existing query.
Grouping, sorting, subtotals, expressions should be implemented.
Report output can be printed as a Postscript file.
For the moment I have no time to do that so volunteers are welcome.
"

21
src/bin/pgaccess/lib/help/reset.hlp Normal file
View File

@ -0,0 +1,21 @@
.pgaw:Help.f.t insert end "RESET" {bold} " restores variables to the default values. Refer to the SET command for details on allowed values and defaults. RESET is an alternate form for SET variable = DEFAULT
" {} "Synopsis" {bold} "
RESET variable
" {} "Usage" {bold} "
-- reset DateStyle to its default;
" {} "
RESET DateStyle;
" {code} "
-- reset Geqo to its default;
" {} "RESET GEQO;
" {code} "Notes" {bold} "
The RESET statement is a Postgres language extension.
Refer to SET/SHOW statements to set/show variable values. "

49
src/bin/pgaccess/lib/help/revoke.hlp Normal file
View File

@ -0,0 +1,49 @@
.pgaw:Help.f.t insert end "REVOKE" {bold} " allows creator of an object to revoke permissions granted before, from all users (via PUBLIC) or a certain user or group.
" {} "Synopsis" {bold} "
" {} "
REVOKE privilege \[, ...\]
ON object \[, ...\]
FROM \{ PUBLIC | GROUP ER\">gBLE> | username \}
" {code} "Usage" {bold} "
-- revoke insert privilege from all users on table films:
--
" {} "REVOKE INSERT ON films FROM PUBLIC;
" {code} "
-- revoke all privileges from user manuel on view kinds:
--
" {} "REVOKE ALL ON kinds FROM manuel;
" {code} "Notes" {bold} "
Refer to psql \\z command for further information about permissions on existing objects:
" {} "
Database = lusitania
+------------------+-------------------------------------------------+
| Relation | Grant/Revoke Permissions |
+------------------+-------------------------------------------------+
| mytable | \{\"=rw\",\"miriam=arwR\",\"group todos=rw\"\} |
+------------------+-------------------------------------------------+
Legend:
uname=arwR -- privileges granted to a user
group gname=arwR -- privileges granted to a GROUP
=arwR -- privileges granted to PUBLIC
r -- SELECT
w -- UPDATE/DELETE
a -- INSERT
R -- RULE
arwR -- ALL
Tip: Currently, to create a GROUP you have to insert data manually into table pg_group as:
INSERT INTO pg_group VALUES ('todos');
CREATE USER miriam IN GROUP todos;
" {code}

17
src/bin/pgaccess/lib/help/rollback.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "ROLLBACK" {bold} " rolls back the current transaction and causes all the updates made by the transaction to be discarded.
" {} "Synopsis" {bold} "
" {} "
ROLLBACK \[ WORK | TRANSACTION \]
" {code} "Usage" {bold} "
" {} "
--To abort all changes:
--
ROLLBACK WORK;
" {code} "Notes" {bold} "
The keywords WORK and TRANSACTION are noise and can be omitted.
Use " {} "COMMIT" {link commit} " to successfully terminate a transaction. "

2
src/bin/pgaccess/lib/help/schema.hlp Normal file
View File

@ -0,0 +1,2 @@
.pgaw:Help.f.t insert end "
To be written"

2
src/bin/pgaccess/lib/help/scripts.hlp Normal file
View File

@ -0,0 +1,2 @@
.pgaw:Help.f.t insert end "
To be written"

136
src/bin/pgaccess/lib/help/select.hlp Normal file
View File

@ -0,0 +1,136 @@
.pgaw:Help.f.t insert end "SELECT" {bold} " will return rows from one or more tables. Candidates for selection are rows which satisfy the WHERE condition; if WHERE is omitted, all rows are candidates.
" {} "Synopsis" {bold} "
" {} "
SELECT \[ALL|DISTINCT \[ON column\] \]
expression \[ AS
name \] \[, ...\]
\[ INTO \[TEMP\] \[TABLE\] new_table \]
\[ FROM table
\[alias \] \[, ...\] \]
\[ WHERE condition \]
\[ GROUP BY column \[, ...\] \]
\[ HAVING condition \[, ...\] \]
\[ { UNION \[ALL\] | INTERSECT | EXCEPT } select \]
\[ ORDER BY column \[ ASC | DESC \] \[, ...\] \]
\[ FOR UPDATE \[OF class_name...\]\]
\[ LIMIT count \[OFFSET|, count\]\]
" {code} "Usage" {bold} "
To join the table films with the table distributors:
" {} "
SELECT f.title, f.did, d.name, f.date_prod, f.kind
FROM distributors d, films f
WHERE f.did = d.did
title |did|name | date_prod|kind
-------------------------+---+----------------+----------+----------
The Third Man |101|British Lion |1949-12-23|Drama
The African Queen |101|British Lion |1951-08-11|Romantic
Une Femme est une Femme |102|Jean Luc Godard |1961-03-12|Romantic
Vertigo |103|Paramount |1958-11-14|Action
Becket |103|Paramount |1964-02-03|Drama
48 Hrs |103|Paramount |1982-10-22|Action
War and Peace |104|Mosfilm |1967-02-12|Drama
West Side Story |105|United Artists |1961-01-03|Musical
Bananas |105|United Artists |1971-07-13|Comedy
Yojimbo |106|Toho |1961-06-16|Drama
There's a Girl in my Soup|107|Columbia |1970-06-11|Comedy
Taxi Driver |107|Columbia |1975-05-15|Action
Absence of Malice |107|Columbia |1981-11-15|Action
Storia di una donna |108|Westward |1970-08-15|Romantic
The King and I |109|20th Century Fox|1956-08-11|Musical
Das Boot |110|Bavaria Atelier |1981-11-11|Drama
Bed Knobs and Broomsticks|111|Walt Disney | |Musical
To sum the column len of all films and group the results by kind:
SELECT kind, SUM(len) AS total FROM films GROUP BY kind;
kind |total
----------+------
Action | 07:34
Comedy | 02:58
Drama | 14:28
Musical | 06:42
Romantic | 04:38
To sum the column len of all films, group the results by kind and show those group totals that are less than 5 hours:
SELECT kind, SUM(len) AS total
FROM films
GROUP BY kind
HAVING SUM(len) < INTERVAL '5 hour';
kind |total
----------+------
Comedy | 02:58
Romantic | 04:38
The following two examples are identical ways of sorting the individual results according to the contents of the second column (name):
SELECT * FROM distributors ORDER BY name;
SELECT * FROM distributors ORDER BY 2;
did|name
---+----------------
109|20th Century Fox
110|Bavaria Atelier
101|British Lion
107|Columbia
102|Jean Luc Godard
113|Luso films
104|Mosfilm
103|Paramount
106|Toho
105|United Artists
111|Walt Disney
112|Warner Bros.
108|Westward
This example shows how to obtain the union of the tables distributors and actors, restricting the results to those that begin with letter W in each table. Only distinct rows are to be used, so
the ALL keyword is omitted:
-- distributors: actors:
-- did|name id|name
-- ---+------------ --+--------------
-- 108|Westward 1|Woody Allen
-- 111|Walt Disney 2|Warren Beatty
-- 112|Warner Bros. 3|Walter Matthau
-- ... ...
SELECT distributors.name
FROM distributors
WHERE distributors.name LIKE 'W%'
UNION
SELECT actors.name
FROM actors
WHERE actors.name LIKE 'W%'
name
--------------
Walt Disney
Walter Matthau
Warner Bros.
Warren Beatty
Westward
Woody Allen
" {code} "Compatibility" {bold} "
Extensions
Postgres allows one to omit the FROM clause from a query. This feature was retained from the original PostQuel query language:
" {} "
SELECT distributors.* WHERE name = 'Westwood';
did|name
---+----------------
108|Westward
" {code}

17
src/bin/pgaccess/lib/help/select_into.hlp Normal file
View File

@ -0,0 +1,17 @@
.pgaw:Help.f.t insert end "SELECT INTO" {bold} " creates a new table from the results of a query. Typically, this query draws data from an existing table, but any SQL query is allowed.
" {} "Synopsis" {bold} "
" {} "
SELECT \[ ALL | DISTINCT \] expression \[ AS name \] \[, ...\]
INTO \[TEMP\] \[ TABLE \] new_table \]
\[ FROM table \[alias\] \[, ...\] \]
\[ WHERE condition \]
\[ GROUP BY column \[, ...\] \]
\[ HAVING condition \[, ...\] \]
\[ { UNION \[ALL\] | INTERSECT | EXCEPT } select\]
\[ ORDER BY column \[ ASC | DESC \] \[, ...\] \]
\[ FOR UPDATE \[OF class_name...\]\]
\[ LIMIT count \[OFFSET|, count\]\]
" {code} "Note" {bold} "
CREATE TABLE AS is functionally equivalent to the SELECT INTO command. "

15
src/bin/pgaccess/lib/help/sequences.hlp Normal file
View File

@ -0,0 +1,15 @@
.pgaw:Help.f.t insert end " The " {} "Sequences" {bold} " tab is used to\
define new sequence number generators or to inspect them.
Sequences are used sometimes for assigning default values to some unique\
fields in order to obtain a unique id. Sequences are returning an int4\
value. For example, a new sequence will be automatically defined if you\
are adding a 'serial' field type into a table.
In order to define a new sequence you should supply at least the sequence\
name. The default increment is 1, the default start value and minvalue is 1.
Inspecting a sequence will show you the last number generated.
For more information see also " {} "CREATE SEQUENCE" {link create_sequence} \
" SQL command." {}

54
src/bin/pgaccess/lib/help/set.hlp Normal file
View File

@ -0,0 +1,54 @@
.pgaw:Help.f.t insert end "SET" {bold} " will modify configuration parameters for variable during a session.
" {} "Synopsis" {bold} "
" {} "
SET variable \{ TO | = \} \{
'value' | DEFAULT \}
SET TIME ZONE \{ 'timezone' | LOCAL | DEFAULT \};
SET TRANSACTION ISOLATION LEVEL \{ READ COMMITTED | SERIALIZED \}
" {code} "Usage" {bold} "
" {} "
--Set the style of date to ISO:
--
SET DATESTYLE TO 'ISO';
--Enable GEQO for queries with 4 or more tables
--
SET GEQO ON=4;
--Set GEQO to default:
--
SET GEQO = DEFAULT;
--set the timezone for Berkeley, California:
SET TIME ZONE 'PST8PDT';
SELECT CURRENT_TIMESTAMP AS today;
today
----------------------
1998-03-31 07:41:21-08
--set the timezone for Italy:
SET TIME ZONE 'Europe/Rome';
SELECT CURRENT_TIMESTAMP AS today;
today
----------------------
1998-03-31 17:41:31+02
" {code} "Notes" {bold} "
The SET variable statement is a Postgres language extension.
Refer to SHOW and RESET to display or reset the current values. "

23
src/bin/pgaccess/lib/help/show.hlp Normal file
View File

@ -0,0 +1,23 @@
.pgaw:Help.f.t insert end "will display the current configuration parameters for variable during a session.
The session can be configured using SET statement, and values can be restored to the defaults using RESET statement. Parameters and values are case-insensitive.
" {} "Synopsis" {bold} "
SHOW variable
" {} "Usage" {bold} "
" {} "
-- show DateStyle;
SHOW DateStyle;
NOTICE:DateStyle is Postgres with US (NonEuropean) conventions
-- show Geqo;
SHOW GEQO;
NOTICE:GEQO is ON
" {code} "Notes" {bold} "
The SHOW is a Postgres language extension.
Refer to SET/RESET to set/reset variable values. See also SET TIME ZONE. "

62
src/bin/pgaccess/lib/help/sql_guide.hlp Normal file
View File

@ -0,0 +1,62 @@
.pgaw:Help.f.t configure -tabs {170 400}
.pgaw:Help.f.t insert end \
"SQL guide\n" {title} \
"
" {} "ABORT" {link abort} " Aborts the current transaction
" {} "ALTER TABLE" {link alter_table} " Modifies table properties
" {} "ALTER USER" {link alter_user} " Modifies user account information
" {} "BEGIN" {link begin} " Begins a transaction in chained mode
" {} "CLOSE" {link close} " Close a cursor
" {} "CLUSTER" {link cluster} " Gives storage clustering advice to the backend
" {} "COMMIT" {link commit} " Commits the current transaction
" {} "COPY" {link copy} " Copies data between files and tables
" {} "CREATE AGGREGATE" {link create_aggregate} " Defines a new aggregate function
" {} "CREATE DATABASE" {link create_database} " Creates a new database
" {} "CREATE FUNCTION" {link create_function} " Defines a new function
" {} "CREATE INDEX" {link create_index} " Constructs a secondary index
" {} "CREATE LANGUAGE" {link create_language} " Defines a new language for functions
" {} "CREATE OPERATOR" {link create_operator} " Defines a new user operator
" {} "CREATE RULE" {link create_rule} " Defines a new rule
" {} "CREATE SEQUENCE" {link create_sequence} " Creates a new sequence number generator
" {} \
"CREATE TABLE" {link create_table} " Creates a new table
" {} "CREATE TABLE AS" {link create_table_as} " Creates a new table
" {} "CREATE TRIGGER" {link create_trigger} " Creates a new trigger
" {} "CREATE TYPE" {link create_type} " Defines a new base data type
" {} "CREATE USER" {link create_user} " Creates account information for a new user
" {} "CREATE VIEW" {link create_view} " Constructs a virtual table
" {} "DECLARE" {link declare} " Defines a cursor for table access
" {} "DELETE" {link delete} " Deletes rows from a table
" {} "DROP AGGREGATE" {link drop_aggregate} " Removes the definition of an aggregate function
" {} "DROP DATABASE" {link drop_database} " Destroys an existing database
" {} "DROP FUNCTION" {link drop_function} " Removes a user-defined C function
" {} "DROP INDEX" {link drop_index} " Removes an index from a database
" {} "DROP LANGUAGE" {link drop_language} " Removes a user-defined procedural language
" {} "DROP OPERATOR" {link drop_operator} " Removes an operator from the database
" {} "DROP RULE" {link drop_rule} " Removes an existing rule from the database
" {} "DROP SEQUENCE" {link drop_sequence} " Removes an existing sequence
" {} "DROP TABLE" {link drop_table} " Removes existing tables from a database
" {} "DROP TRIGGER" {link drop_trigger} " Removes the definition of a trigger
" {} "DROP TYPE" {link drop_type} " Removes a user-defined type from the system catalogs
" {} "DROP USER" {link drop_user} " Removes an user account information
" {} "DROP VIEW" {link drop_view} " Removes an existing view from a database
" {} "EXPLAIN" {link explain} " Shows statement execution details
" {} "FETCH" {link fetch} " Gets rows using a cursor
" {} "GRANT" {link grant} " Grants access privilege to a user, a group or all users
" {} "INSERT" {link insert} " Inserts new rows into a table
" {} "LISTEN" {link listen} " Listen for notification on a notify condition
" {} "LOAD" {link load} " Dynamically loads an object file
" {} "LOCK" {link lock} " Explicit lock of a table inside a transaction
" {} "MOVE" {link move} " Moves cursor position
" {} "NOTIFY" {link notify} " Signals all frontends and backends listening on a notify condition
" {} "RESET" {link reset} " Restores run-time parameters for session to default values
" {} "REVOKE" {link revoke} " Revokes access privilege from a user, a group or all users.
" {} "ROLLBACK" {link rollback} " Aborts the current transaction
" {} "SELECT" {link select} " Retrieve rows from a table or view.
" {} "SELECT INTO" {link select_into} " Create a new table from an existing table or view
" {} "SET" {link set} " Set run-time parameters for session
" {} "SHOW" {link show} " Shows run-time parameters for session
" {} "UNLISTEN" {link unlisten} " Stop listening for notification
" {} "UPDATE" {link update} " Replaces values of columns in a table
" {} "VACUUM" {link vacuum} " Clean and analyze a Postgres database
"

21
src/bin/pgaccess/lib/help/sqlfunc.hlp Normal file
View File

@ -0,0 +1,21 @@
.pgaw:Help.f.t insert end \
"SQL functions\n\n" {title} \
"COALESCE(list)" {bold} "
return first non-NULL value in list
Example:
COALESCE(a2, c2 + 5, 0)
" {} "IFNULL(input,non-NULL substitute)" {bold} "
return second argument if first is NULL
Example:
IFNULL(c1, 'N/A')
" {} "CASE WHEN expr THEN expr \[...\] ELSE expr END" {bold} "
return expression for first true clause
Example:
CASE WHEN c1 = 1 THEN 'match' ELSE 'no match' END
" {} \
"PostgreSQL functions\n" {link pgfunctions} \
"Next - mathematical functions" {link mathfunc}

102
src/bin/pgaccess/lib/help/stringfunc.hlp Normal file
View File

@ -0,0 +1,102 @@
.pgaw:Help.f.t insert end \
"String functions\n\n" {title} \
"SQL92 String Functions" {bold} \
" - SQL92 defines string functions with specific syntax. Some of these are implemented using other Postgres functions. The supported string types for SQL92 are char, varchar, and text.
" {} "
char_length(string)" {bold} "
Returns: int4
length of string" {} "
character_length(string)" {bold} "
Returns: int4
length of string" {} "
lower(string)" {bold} "
Returns: string
convert string to lower case" {} "
octet_length(string)" {bold} "
Returns: int4
storage length of string" {} "
position(string in string)" {bold} "
Returns: int4
location of specified substring" {} "
substring(string \[from int\] \[for int\])" {bold} "
Returns: string
extract specified substring" {} "
trim(\[leading|trailing|both\] \[string\] from string)" {bold} "
Returns: string
trim characters from string" {} "
upper(text)" {bold} "
Returns: text
convert text to upper case
Many additional string functions are available for text, varchar(), and char() types. Some are used internally to implement the SQL92 string functions listed above.
" {} "PostgreSQL String Functions
char(text)" {bold} "
Returns: char
convert text to char type
" {} "char(varchar)" {bold} "
Returns: char
convert varchar to char type
" {} "initcap(text)" {bold} "
Returns: text
first letter of each word to upper case
" {} "lpad(text,int,text)" {bold} "
Returns: text
left pad string to specified length
" {} "ltrim(text,text)" {bold} "
Returns: text
left trim characters from text
" {} "textpos(text,text)" {bold} "
Returns:text
locate specified substring
" {} "rpad(text,int,text)" {bold} "
Returns: text
right pad string to specified length
" {} "rtrim(text,text)" {bold} "
Returns: text
right trim characters from text
" {} "substr(text,int\[,int\])" {bold} "
Returns: text
extract specified substring
" {} "text(char)" {bold} "
Returns: text
convert char to text type
" {} "text(varchar)" {bold} "
Returns: text
convert varchar to text type
" {} "translate(text,from,to)" {bold} "
Returns: text
convert character in string
" {} "varchar(char)" {bold} "
Returns: varchar
convert char to varchar type
" {} "varchar(text)" {bold} "
Returns: varchar
convert text to varchar type
Most functions explicitly defined for text will work for char() and varchar() arguments.
" {} \
"PostgreSQL functions\n" {link pgfunctions} \
"Next - Date/Time functions" {link datefunc}

8
src/bin/pgaccess/lib/help/tables.hlp Normal file
View File

@ -0,0 +1,8 @@
.pgaw:Help.f.t insert end \
"Tables" {title} \
"\n\n" {} \
" The following topics are available:\n" {} \
" creating a new table\n" {link new_table} \
" opening a table for viewing and editing\n" {link open_table} \
" adding new records to an existing table\n" {link add_records} \
" viewing and changing table structure\n" {link view_table_structure}

32
src/bin/pgaccess/lib/help/unlisten.hlp Normal file
View File

@ -0,0 +1,32 @@
.pgaw:Help.f.t insert end "UNLISTEN" {bold} " is used to remove an existing NOTIFY registration. UNLISTEN cancels any existing registration of the current Postgres session as a listener on the notify condition notifyname. \
The special condition wildcard \"*\" cancels all listener registrations for the current session.
" {} "NOTIFY" {link notify} " contains a more extensive discussion of the use of LISTEN and NOTIFY.
" {} "Synopsis" {bold} "
" {} "
UNLISTEN \{ notifyname | * \}
" {code} "Usage" {bold} "
" {} "
postgres=> LISTEN virtual;
LISTEN
postgres=> NOTIFY virtual;
NOTIFY
ASYNC NOTIFY of 'virtual' from backend pid '12317' received
postgres=> UNLISTEN virtual;
UNLISTEN
postgres=> NOTIFY virtual;
NOTIFY
-- notice no NOTIFY event is received
postgres=>
" {code} "Notes" {bold} "
classname needs not to be a valid class name but can be any string valid as a name up to 32 characters long.
The backend does not complain if you UNLISTEN something you were not listening for. Each backend will automatically execute UNLISTEN * when exiting.
A restriction in some previous releases of Postgres that a classname which does not correspond to an actual table must be enclosed in double-quotes is no longer present.
"

40
src/bin/pgaccess/lib/help/update.hlp Normal file
View File

@ -0,0 +1,40 @@
.pgaw:Help.f.t insert end "UPDATE" {bold} " changes the values of the columns specified for all rows which satisfy condition. Only the columns to be modified need appear as column.
Array references use the same syntax found in SELECT. That is, either single array elements, a range of array elements or the entire array may be replaced with a single query.
You must have write access to the table in order to modify it, as well as read access to any table whose values are mentioned in the WHERE condition.
" {} "Synopsis" {bold} "
" {} "
UPDATE table SET column = expression \[, ...\]
\[ FROM fromlist \]
\[ WHERE condition \]
" {code} "Usage" {bold} "
" {} "
--Change word \"Drama\" with \"Dramatic\" on column kind:
--
UPDATE films
SET kind = 'Dramatic'
WHERE kind = 'Drama';
SELECT * FROM films WHERE kind = 'Dramatic' OR kind = 'Drama';
code |title |did| date_prod|kind |len
-----+-------------+---+----------+----------+------
BL101|The Third Man|101|1949-12-23|Dramatic | 01:44
P_302|Becket |103|1964-02-03|Dramatic | 02:28
M_401|War and Peace|104|1967-02-12|Dramatic | 05:57
T_601|Yojimbo |106|1961-06-16|Dramatic | 01:50
DA101|Das Boot |110|1981-11-11|Dramatic | 02:29
" {code} "Compatibility" {bold} "
SQL92
SQL92 defines a different syntax for positioned UPDATE statement:
" {} "
UPDATE table SET column = expression \[, ...\]
WHERE CURRENT OF cursor
" {code} "where cursor identifies an open cursor. "

2
src/bin/pgaccess/lib/help/users.hlp Normal file
View File

@ -0,0 +1,2 @@
.pgaw:Help.f.t insert end "
To be written"

26
src/bin/pgaccess/lib/help/vacuum.hlp Normal file
View File

@ -0,0 +1,26 @@
.pgaw:Help.f.t insert end \
"VACUUM" {bold} " serves two purposes in Postgres as both a means to reclaim storage and also a means to collect information for the optimizer.
VACUUM opens every class in the database, cleans out records from rolled back transactions, and updates statistics in the system catalogs. The statistics maintained include the number of tuples and number of pages stored in all classes. Running VACUUM periodically will increase the speed of the database in processing user queries.
" {} "Notes:" {italic} " The open database is target for VACUUM.
We recommend that active production databases be cleaned nightly, in order to keep statistics relatively current. The VACUUM query may be executed at any time, however. In particular, after copying a large class into Postgres or after deleting a large number of records, it may be a good idea to issue a VACUUM query. This will update the system catalogs with the results of all recent changes, and allow the Postgres query optimizer to make better choices in planning user queries.
If the server crashes during a VACUUM command, chances are it will leave a lock file hanging around. Attempts to re-run the VACUUM command result in an error message about the creation of a lock file. If you are sure VACUUM is not running, remove the pg_vlock file in your database directory (i.e. PGDATA/base/dbname/pg_vlock).
" {} "Synopsis" {bold} "
VACUUM \[ VERBOSE \] \[ ANALYZE \] \[ table \]
VACUUM \[ VERBOSE \] ANALYZE \[ table \[ (column \[, ...\] ) \] \]
" {code} "VERBOSE" {italic} "
Prints a detailed vacuum activity report for each table.
" {} "ANALYZE" {italic} "
Updates column statistics used by the optimizer to determine the most efficient way to execute a query. The statistics represent the disbursion of the data in each column. This information is valuable when several execution paths are possible.
" {} "table" {italic} "
The name of a specific table to vacuum. Defaults to all tables.
" {} "column" {italic} "
The name of a specific column to analyze. Defaults to all columns. "

15
src/bin/pgaccess/lib/help/view_table_structure.hlp Normal file
View File

@ -0,0 +1,15 @@
.pgaw:Help.f.t insert end \
"View and change table structure" {bold} "
Select the Tables tab from the main window , select the desired table and press the \"Design\" button. You will get a tabbed dialog containing general information for the table, table structure, index information and permissions.
You will be able to add new fields, rename the existing ones and add new indexes. In order to add a new index, select the fields that will be included in the index (multiple selections with shift-click) and press the \"Add new index\" button.
A confirmation form will be displayed. The index name will be asigned by default by concatenating using underscore the table name with the fields names but you can change it as you will. Checking the \"Is unique?\" check box will force the creation of a unique index.
You can inspect the properties of a index by selecting it from the list of defined indexes. You can also delete one of them by selecting the index and then pressing the \"Delete index\" button.\
You can cluster an index fo the table, more information on " {} "cluster SQL command" {link cluster} "
Through \"Permissions\" tab you can assign new permissions for the table or alter the existing ones. See also " {} "GRANT" {link grant} " and " {} "REVOKE" {link revoke} " SQL commands."

2
src/bin/pgaccess/lib/help/views.hlp Normal file
View File

@ -0,0 +1,2 @@
.pgaw:Help.f.t insert end "
To be written"

57
src/bin/pgaccess/lib/help/visual_designer.hlp Normal file
View File

@ -0,0 +1,57 @@
.pgaw:Help.f.t insert end \
"Visual query designer" {bold} "
PgAccess is using an advanced tool for visual designing of queries. \
For those of you that have used Microsoft Access, it will be very familiar.
When a new query is build, an empty canvas will be presented to you. \
In the bottom of the screen there is the " {} "result" {italic} " zone.
Add new tables on the canvas by selecting them from the drop-down or by entering \
their names in the \"Add table\" entry and then pressing Enter.
After adding the source tables on the canvas you can make links between fields from \
different tables by dragging one field and dropping it on the label of the\
corresponding field in the linked table. Links can be deleted by selecting them\
(the link line will change it's colour) and then press \"Delete\" key.
In order to delete a table from the canvas, select it by mouse clicking on the\
name of the table and then press the \"Delete\" key. The tables can be moved\
on the canvas by dragging them from their name labels. The entire canvas can\
be panned by dragging it from an empty area.
In order to select fields that will be included in the result, drag the desired \
field from the table and drop it in the result zone in the desired column.\
If there is already another field in that column, it will be shifted to the \
right together with all the remaining fields to the right and the new field will \
be inserted in the desired column.
You can also specify a condition for records to be included in the result. Go \
to the result zone and in the \"Criteria\" row enter the condition for the \
selected field." {} "
Example:" {italic} "
> 150
we will presume that we entered the above criteria for a numeric field. Or:
= 'CPU'
for a character field.
If you don't want a field to be included in the result and you dropped it into \
the result area just for adding a selection criteria on it, mouse click on \
the Yes or No label in the \"Return\" row.
In order to sort the results on a field, mouse click on the 'unsorted' label in \
the \"Sort\" row.
If you want to remove a field from the result zone, click on it's name and \
then hit the \"Delete\" key.
Pressing the \"Show SQL\" button will display the SQL command that will be \
build from the current tables and result columns. Clicking on the canvas will \
make it dissapear and the table layout will be displayed again.
Check the query execution by pressing on the \"Execute SQL\" button. If the \
query has been executed without error, a query viewer will be displayed and \
you will be able to see the selected rows. When everything is ok, save the \
query command to the query builder by pressing the \"Save to query builder\" \
button.
"

16
src/bin/pgaccess/lib/help/y2k.hlp Normal file
View File

@ -0,0 +1,16 @@
.pgaw:Help.f.t insert end \
"Year 2000 statement\n\n" {title} \
"Author : " {bold} "Written by Thomas Lockhart on 1998-10-22\n" {} \
{
The PostgreSQL Global Development Team provides the Postgres software code tree as a public service, without warranty and without liability for it's behavior or performance. However, at the time of writing:
The author of this statement, a volunteer on the Postgres support team since November, 1996, is not aware of any problems in the Postgres code base related to time transitions around Jan 1, 2000 (Y2K).
The author of this statement is not aware of any reports of Y2K problems uncovered in regression testing or in other field use of recent or current versions of Postgres. We might have expected to hear about problems if they existed, given the installed base and the active participation of users on the support mailing lists.
To the best of the author's knowledge, the assumptions Postgres makes about dates specified with a two-digit year are documented in the current User's Guide in the chapter on data types. For two-digit years, the significant transition year is 1970, not 2000; e.g. "70-01-01" is interpreted as "1970-01-01", whereas "69-01-01" is interpreted as "2069-01-01".
Any Y2K problems in the underlying OS related to obtaining "the current time" may propagate into apparent Y2K problems in Postgres.
Refer to The Gnu Project and The Perl Institute for further discussion of Y2K issues, particularly as it relates to open source, no fee software.
}