You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hawq.apache.org by yo...@apache.org on 2017/01/06 17:32:28 UTC
[13/51] [partial] incubator-hawq-docs git commit: HAWQ-1254
Fix/remove book branching on incubator-hawq-docs
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-SEQUENCE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-SEQUENCE.html.md.erb b/markdown/reference/sql/DROP-SEQUENCE.html.md.erb
new file mode 100644
index 0000000..59c0d85
--- /dev/null
+++ b/markdown/reference/sql/DROP-SEQUENCE.html.md.erb
@@ -0,0 +1,45 @@
+---
+title: DROP SEQUENCE
+---
+
+Removes a sequence.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP SEQUENCE [IF EXISTS] <name> [, ...] [CASCADE | RESTRICT]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP SEQUENCE` removes a sequence generator table. You must own the sequence to drop it (or be a superuser).
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the sequence does not exist. A notice is issued in this case.</dd>
+
+<dt>\<name\> </dt>
+<dd>The name (optionally schema-qualified) of the sequence to remove.</dd>
+
+<dt>CASCADE </dt>
+<dd>Automatically drop objects that depend on the sequence.</dd>
+
+<dt>RESTRICT </dt>
+<dd>Refuse to drop the sequence if any objects depend on it. This is the default.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Remove the sequence `myserial`:
+
+``` pre
+DROP SEQUENCE myserial;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`DROP SEQUENCE` is fully conforming with the SQL standard, except that the standard only allows one sequence to be dropped per command. Also, the `IF EXISTS` option is a HAWQ extension.
+
+## <a id="topic1__section7"></a>See Also
+
+[CREATE SEQUENCE](CREATE-SEQUENCE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-TABLE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-TABLE.html.md.erb b/markdown/reference/sql/DROP-TABLE.html.md.erb
new file mode 100644
index 0000000..b277273
--- /dev/null
+++ b/markdown/reference/sql/DROP-TABLE.html.md.erb
@@ -0,0 +1,47 @@
+---
+title: DROP TABLE
+---
+
+Removes a table.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP TABLE [IF EXISTS] <name> [, ...] [CASCADE | RESTRICT]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP TABLE` removes tables from the database. Only its owner may drop a table. To empty a table of rows without removing the table definition, use `TRUNCATE`.
+
+`DROP TABLE` always removes any indexes, rules, and constraints that exist for the target table. However, to drop a table that is referenced by a view, `CASCADE` must be specified. `CASCADE` will remove a dependent view entirely.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the table does not exist. A notice is issued in this case.</dd>
+
+<dt>\<name\> </dt>
+<dd>The name (optionally schema-qualified) of the table to remove.</dd>
+
+<dt>CASCADE </dt>
+<dd>Automatically drop objects that depend on the table (such as views).</dd>
+
+<dt>RESTRICT </dt>
+<dd>Refuse to drop the table if any objects depend on it. This is the default.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Remove the table `mytable`:
+
+``` pre
+DROP TABLE mytable;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`DROP TABLE` is fully conforming with the SQL standard, except that the standard only allows one table to be dropped per command. Also, the `IF EXISTS` option is a HAWQ extension.
+
+## <a id="topic1__section7"></a>See Also
+
+[CREATE TABLE](CREATE-TABLE.html), [ALTER TABLE](ALTER-TABLE.html), [TRUNCATE](TRUNCATE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-TABLESPACE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-TABLESPACE.html.md.erb b/markdown/reference/sql/DROP-TABLESPACE.html.md.erb
new file mode 100644
index 0000000..9ffdfef
--- /dev/null
+++ b/markdown/reference/sql/DROP-TABLESPACE.html.md.erb
@@ -0,0 +1,42 @@
+---
+title: DROP TABLESPACE
+---
+
+Removes a tablespace.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP TABLESPACE [IF EXISTS] <tablespacename>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP TABLESPACE` removes a tablespace from the system.
+
+A tablespace can only be dropped by its owner or a superuser. The tablespace must be empty of all database objects before it can be dropped. It is possible that objects in other databases may still reside in the tablespace even if no objects in the current database are using the tablespace.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the tablespace does not exist. A notice is issued in this case.</dd>
+
+<dt>\<tablespacename\> </dt>
+<dd>The name of the tablespace to remove.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Remove the tablespace `mystuff`:
+
+``` pre
+DROP TABLESPACE mystuff;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`DROP TABLESPACE` is a HAWQ extension.
+
+## <a id="topic1__section7"></a>See Also
+
+[CREATE TABLESPACE](CREATE-TABLESPACE.html), [ALTER TABLESPACE](ALTER-TABLESPACE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-TYPE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-TYPE.html.md.erb b/markdown/reference/sql/DROP-TYPE.html.md.erb
new file mode 100644
index 0000000..1ffd44a
--- /dev/null
+++ b/markdown/reference/sql/DROP-TYPE.html.md.erb
@@ -0,0 +1,45 @@
+---
+title: DROP TYPE
+---
+
+Removes a data type.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP TYPE [IF EXISTS] <name> [, ...] [CASCADE | RESTRICT]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP TYPE` will remove a user-defined data type. Only the owner of a type can remove it.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the type does not exist. A notice is issued in this case.</dd>
+
+<dt>\<name\> </dt>
+<dd>The name (optionally schema-qualified) of the data type to remove.</dd>
+
+<dt>CASCADE </dt>
+<dd>Automatically drop objects that depend on the type (such as table columns, functions, operators).</dd>
+
+<dt>RESTRICT </dt>
+<dd>Refuse to drop the type if any objects depend on it. This is the default.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Remove the data type `box`;
+
+``` pre
+DROP TYPE box;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+This command is similar to the corresponding command in the SQL standard, apart from the `IF EXISTS` option, which is a HAWQ extension. But note that the `CREATE TYPE` command and the data type extension mechanisms in HAWQ differ from the SQL standard.
+
+## <a id="topic1__section7"></a>See Also
+
+[ALTER TYPE](ALTER-TYPE.html), [CREATE TYPE](CREATE-TYPE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-USER.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-USER.html.md.erb b/markdown/reference/sql/DROP-USER.html.md.erb
new file mode 100644
index 0000000..6ab3992
--- /dev/null
+++ b/markdown/reference/sql/DROP-USER.html.md.erb
@@ -0,0 +1,31 @@
+---
+title: DROP USER
+---
+
+Removes a database role.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP USER [IF EXISTS] <name> [, ...]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP USER` is an obsolete command, though still accepted for backwards compatibility. Groups (and users) have been superseded by the more general concept of roles. See [DROP ROLE](DROP-ROLE.html) for more information.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the role does not exist. A notice is issued in this case.</dd>
+
+<dt>\<name\> </dt>
+<dd>The name of an existing role.</dd>
+
+## <a id="topic1__section5"></a>Compatibility
+
+There is no `DROP USER` statement in the SQL standard. The SQL standard leaves the definition of users to the implementation.
+
+## <a id="topic1__section6"></a>See Also
+
+[DROP ROLE](DROP-ROLE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/DROP-VIEW.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/DROP-VIEW.html.md.erb b/markdown/reference/sql/DROP-VIEW.html.md.erb
new file mode 100644
index 0000000..b8b9968
--- /dev/null
+++ b/markdown/reference/sql/DROP-VIEW.html.md.erb
@@ -0,0 +1,45 @@
+---
+title: DROP VIEW
+---
+
+Removes a view.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+DROP VIEW [IF EXISTS] <name. [, ...] [CASCADE | RESTRICT]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`DROP VIEW` will remove an existing view. Only the owner of a view can remove it.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>IF EXISTS </dt>
+<dd>Do not throw an error if the view does not exist. A notice is issued in this case.</dd>
+
+<dt>\<name\> </dt>
+<dd>The name (optionally schema-qualified) of the view to remove.</dd>
+
+<dt>CASCADE </dt>
+<dd>Automatically drop objects that depend on the view (such as other views).</dd>
+
+<dt>RESTRICT </dt>
+<dd>Refuse to drop the view if any objects depend on it. This is the default.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Remove the view `topten`;
+
+``` pre
+DROP VIEW topten;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`DROP VIEW` is fully conforming with the SQL standard, except that the standard only allows one view to be dropped per command. Also, the `IF EXISTS` option is a HAWQ extension.
+
+## <a id="topic1__section7"></a>See Also
+
+[CREATE VIEW](CREATE-VIEW.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/END.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/END.html.md.erb b/markdown/reference/sql/END.html.md.erb
new file mode 100644
index 0000000..484afcf
--- /dev/null
+++ b/markdown/reference/sql/END.html.md.erb
@@ -0,0 +1,37 @@
+---
+title: END
+---
+
+Commits the current transaction.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+END [WORK | TRANSACTION]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`END` commits the current transaction. All changes made by the transaction become visible to others and are guaranteed to be durable if a crash occurs. This command is a HAWQ extension that is equivalent to [COMMIT](COMMIT.html).
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>WORK
+TRANSACTION </dt>
+<dd>Optional keywords. They have no effect.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Commit the current transaction:
+
+``` pre
+END;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`END` is a HAWQ extension that provides functionality equivalent to [COMMIT](COMMIT.html), which is specified in the SQL standard.
+
+## <a id="topic1__section7"></a>See Also
+
+[BEGIN](BEGIN.html), [ROLLBACK](ROLLBACK.html), [COMMIT](COMMIT.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/EXECUTE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/EXECUTE.html.md.erb b/markdown/reference/sql/EXECUTE.html.md.erb
new file mode 100644
index 0000000..ff57cc6
--- /dev/null
+++ b/markdown/reference/sql/EXECUTE.html.md.erb
@@ -0,0 +1,45 @@
+---
+title: EXECUTE
+---
+
+Executes a prepared SQL statement.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+EXECUTE <name> [ (<parameter> [, ...] ) ]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`EXECUTE` is used to execute a previously prepared statement. Since prepared statements only exist for the duration of a session, the prepared statement must have been created by a `PREPARE` statement executed earlier in the current session.
+
+If the `PREPARE` statement that created the statement specified some parameters, a compatible set of parameters must be passed to the `EXECUTE` statement, or else an error is raised. Note that (unlike functions) prepared statements are not overloaded based on the type or number of their parameters; the name of a prepared statement must be unique within a database session.
+
+For more information on the creation and usage of prepared statements, see `PREPARE`.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>\<name\> </dt>
+<dd>The name of the prepared statement to execute.</dd>
+
+<dt>\<parameter\> </dt>
+<dd>The actual value of a parameter to the prepared statement. This must be an expression yielding a value that is compatible with the data type of this parameter, as was determined when the prepared statement was created.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Create a prepared statement for an `INSERT` statement, and then execute it:
+
+``` pre
+PREPARE fooplan (int, text, bool, numeric) AS INSERT INTO
+foo VALUES($1, $2, $3, $4);
+EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+The SQL standard includes an `EXECUTE` statement, but it is only for use in embedded SQL. This version of the `EXECUTE` statement also uses a somewhat different syntax.
+
+## <a id="topic1__section7"></a>See Also
+
+[DEALLOCATE](DEALLOCATE.html), [PREPARE](PREPARE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/EXPLAIN.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/EXPLAIN.html.md.erb b/markdown/reference/sql/EXPLAIN.html.md.erb
new file mode 100644
index 0000000..ca0e908
--- /dev/null
+++ b/markdown/reference/sql/EXPLAIN.html.md.erb
@@ -0,0 +1,96 @@
+---
+title: EXPLAIN
+---
+
+Shows the query plan of a statement.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+EXPLAIN [ANALYZE] [VERBOSE] <statement>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`EXPLAIN` displays the query plan that the HAWQ planner generates for the supplied statement. Query plans are a tree plan of nodes. Each node in the plan represents a single operation, such as table scan, join, aggregation or a sort.
+
+Plans should be read from the bottom up as each node feeds rows into the node directly above it. The bottom nodes of a plan are usually table scan operations. If the query requires joins, aggregations, or sorts (or other operations on the raw rows), then there will be additional nodes above the scan nodes to perform these operations. The topmost plan nodes are usually the HAWQ motion nodes (redistribute, explicit redistribute, broadcast, or gather motions). These are the operations responsible for moving rows between the segment instances during query processing.
+
+The output of `EXPLAIN` has one line for each node in the plan tree, showing the basic node type plus the following cost estimates that the planner made for the execution of that plan node:
+
+- **cost** \u2014 measured in units of disk page fetches; that is, 1.0 equals one sequential disk page read. The first estimate is the start-up cost (cost of getting to the first row) and the second is the total cost (cost of getting all rows). Note that the total cost assumes that all rows will be retrieved, which may not always be the case (if using `LIMIT` for example).
+- **rows** \u2014 the total number of rows output by this plan node. This is usually less than the actual number of rows processed or scanned by the plan node, reflecting the estimated selectivity of any `WHERE` clause conditions. Ideally the top-level nodes estimate will approximate the number of rows actually returned, updated, or deleted by the query.
+- **width** \u2014 total bytes of all the rows output by this plan node.
+
+It is important to note that the cost of an upper-level node includes the cost of all its child nodes. The topmost node of the plan has the estimated total execution cost for the plan. This is this number that the planner seeks to minimize. It is also important to realize that the cost only reflects things that the query planner cares about. In particular, the cost does not consider the time spent transmitting result rows to the client.
+
+`EXPLAIN ANALYZE` causes the statement to be actually executed, not only planned. The `EXPLAIN ANALYZE` plan shows the actual results along with the planner's estimates. This is useful for seeing whether the planner's estimates are close to reality. In addition to the information shown in the `EXPLAIN` plan, `EXPLAIN ANALYZE` will show the following additional information:
+
+- The total elapsed time (in milliseconds) that it took to run the query.
+- The number of *workers* (segments) involved in a plan node operation. Only segments that return rows are counted.
+- The maximum number of rows returned by the segment that produced the most rows for an operation. If multiple segments produce an equal number of rows, the one with the longest *time to end* is the one chosen.
+- The segment id number of the segment that produced the most rows for an operation.
+- For relevant operations, the *work\_mem* used by the operation. If *work\_mem* was not sufficient to perform the operation in memory, the plan will show how much data was spilled to disk and how many passes over the data were required for the lowest performing segment. For example:
+
+ ``` pre
+ Work_mem used: 64K bytes avg, 64K bytes max (seg0).
+ Work_mem wanted: 90K bytes avg, 90K bytes max (seg0) to abate workfile
+ I/O affecting 2 workers.
+ [seg0] pass 0: 488 groups made from 488 rows; 263 rows written to
+ workfile
+ [seg0] pass 1: 263 groups made from 263 rows
+ ```
+**Note**
+You cannot set the *work\_mem* property. The *work\_mem* property is for information only.
+
+- The time (in milliseconds) it took to retrieve the first row from the segment that produced the most rows, and the total time taken to retrieve all rows from that segment. The `\<time\> to first row` may be omitted if it is the same as the `\<time\> to end`.
+
+**Important:**
+Keep in mind that the statement is actually executed when `EXPLAIN ANALYZE` is used. Although `EXPLAIN ANALYZE` will discard any output that a `SELECT` would return, other side effects of the statement will happen as usual. If you wish to use `EXPLAIN ANALYZE` on a DML statement without letting the command affect your data, use this approach:
+
+``` pre
+BEGIN;
+EXPLAIN ANALYZE ...;
+ROLLBACK;
+```
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>\<name\> </dt>
+<dd>The name of the prepared statement to execute.</dd>
+
+<dt>\<parameter\> </dt>
+<dd>The actual value of a parameter to the prepared statement. This must be an expression yielding a value that is compatible with the data type of this parameter, as was determined when the prepared statement was created.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+In order to allow the query planner to make reasonably informed decisions when optimizing queries, the `ANALYZE` statement should be run to record statistics about the distribution of data within the table. If you have not done this (or if the statistical distribution of the data in the table has changed significantly since the last time `ANALYZE` was run), the estimated costs are unlikely to conform to the real properties of the query, and consequently an inferior query plan may be chosen.
+
+## <a id="topic1__section6"></a>Examples
+
+To illustrate how to read an `EXPLAIN` query plan, consider the following example for a very simple query:
+
+``` pre
+EXPLAIN SELECT * FROM names WHERE name = 'Joelle';
+���������������������QUERY PLAN
+------------------------------------------------------------
+Gather Motion 2:1 (slice1) (cost=0.00..20.88 rows=1 width=13)
+
+���-> Seq Scan on 'names' (cost=0.00..20.88 rows=1 width=13)
+ ������Filter: name::text ~~ 'Joelle'::text
+```
+
+If we read the plan from the bottom up, the query planner starts by doing a sequential scan of the `names` table. Notice that the `WHERE` clause is being applied as a *filter* condition. This means that the scan operation checks the condition for each row it scans, and outputs only the ones that pass the condition.
+
+The results of the scan operation are passed up to a *gather motion* operation. In HAWQ, a gather motion is when segments send rows up to the master. In this case we have 2 segment instances sending to 1 master instance (2:1). This operation is working on `slice1` of the parallel query execution plan. In HAWQ, a query plan is divided into *slices* so that portions of the query plan can be worked on in parallel by the segments.
+
+The estimated startup cost for this plan is `00.00` (no cost) and a total cost of `20.88` disk page fetches. The planner is estimating that this query will return one row.
+
+## <a id="topic1__section7"></a>Compatibility
+
+There is no `EXPLAIN` statement defined in the SQL standard.
+
+## <a id="topic1__section8"></a>See Also
+
+[ANALYZE](ANALYZE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/FETCH.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/FETCH.html.md.erb b/markdown/reference/sql/FETCH.html.md.erb
new file mode 100644
index 0000000..bdd9292
--- /dev/null
+++ b/markdown/reference/sql/FETCH.html.md.erb
@@ -0,0 +1,146 @@
+---
+title: FETCH
+---
+
+Retrieves rows from a query using a cursor.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+FETCH [ <forward_direction> { FROM | IN } ] <cursorname>
+
+```
+
+where *forward\_direction* can be empty or one of:
+
+``` pre
+����NEXT
+����FIRST
+����LAST
+����ABSOLUTE <count>
+����RELATIVE <count>
+����<count>
+����ALL
+����FORWARD
+����FORWARD <count>
+����FORWARD ALL
+```
+
+## <a id="topic1__section3"></a>Description
+
+`FETCH` retrieves rows using a previously-created cursor.
+
+A cursor has an associated position, which is used by `FETCH`. The cursor position can be before the first row of the query result, on any particular row of the result, or after the last row of the result. When created, a cursor is positioned before the first row. After fetching some rows, the cursor is positioned on the row most recently retrieved. If `FETCH` runs off the end of the available rows then the cursor is left positioned after the last row. `FETCH ALL` will always leave the cursor positioned after the last row.
+
+The forms `NEXT`, `FIRST`, `LAST`, `ABSOLUTE`, `RELATIVE` fetch a single row after moving the cursor appropriately. If there is no such row, an empty result is returned, and the cursor is left positioned before the first row or after the last row as appropriate.
+
+The forms using `FORWARD` retrieve the indicated number of rows moving in the forward direction, leaving the cursor positioned on the last-returned row (or after all rows, if the count exceeds the number of rows available). Note that it is not possible to move a cursor position backwards in HAWQ, since scrollable cursors are not supported. You can only move a cursor forward in position using `FETCH`.
+
+`RELATIVE 0` and `FORWARD 0` request fetching the current row without moving the cursor, that is, re-fetching the most recently fetched row. This will succeed unless the cursor is positioned before the first row or after the last row, in which case no row is returned.
+
+**Outputs**
+
+On successful completion, a `FETCH` command returns a command tag of the form
+
+``` pre
+FETCH count
+
+```
+
+The count is the number of rows fetched (possibly zero). Note that in `psql`, the command tag will not actually be displayed, since `psql` displays the fetched rows instead.
+
+## <a id="topic1__section5"></a>Parameters
+
+<dt>\<forward\_direction\> </dt>
+<dd>Defines the fetch direction and number of rows to fetch. Only forward fetches are allowed in HAWQ. It can be one of the following:</dd>
+
+<dt>NEXT </dt>
+<dd>Fetch the next row. This is the default if direction is omitted.</dd>
+
+<dt>FIRST </dt>
+<dd>Fetch the first row of the query (same as `ABSOLUTE 1`). Only allowed if it is the first `FETCH` operation using this cursor.</dd>
+
+<dt>LAST </dt>
+<dd>Fetch the last row of the query (same as `ABSOLUTE -1`).</dd>
+
+<dt>ABSOLUTE \<count\> </dt>
+<dd>Fetch the specified row of the query. Position after last row if count is out of range. Only allowed if the row specified by *count* moves the cursor position forward.</dd>
+
+<dt>RELATIVE \<count\> </dt>
+<dd>Fetch the specified row of the query *count* rows ahead of the current cursor position. `RELATIVE 0` re-fetches the current row, if any. Only allowed if *count* moves the cursor position forward.</dd>
+
+<dt>\<count\> </dt>
+<dd>Fetch the next *count* number of rows (same as `FORWARD count `).</dd>
+
+<dt>ALL </dt>
+<dd>Fetch all remaining rows (same as `FORWARD ALL`).</dd>
+
+<dt>FORWARD </dt>
+<dd>Fetch the next row (same as `NEXT`).</dd>
+
+<dt>FORWARD \<count\> </dt>
+<dd>Fetch the next *count* number of rows. `FORWARD 0` re-fetches the current row.</dd>
+
+<dt>FORWARD ALL </dt>
+<dd>Fetch all remaining rows.</dd>
+
+<dt>\<cursorname\> </dt>
+<dd>The name of an open cursor.</dd>
+
+## <a id="topic1__section6"></a>Notes
+
+HAWQ does not support scrollable cursors, so you can only use `FETCH` to move the cursor position forward.
+
+`ABSOLUTE` fetches are not any faster than navigating to the desired row with a relative move: the underlying implementation must traverse all the intermediate rows anyway.
+
+Updating data via a cursor is currently not supported by HAWQ.
+
+`DECLARE` is used to define a cursor. Use `MOVE` to change cursor position without retrieving data.
+
+## <a id="topic1__section7"></a>Examples
+
+-- Start the transaction:
+
+``` pre
+BEGIN;
+```
+
+-- Set up a cursor:
+
+``` pre
+DECLARE mycursor CURSOR FOR SELECT * FROM films;
+```
+
+-- Fetch the first 5 rows in the cursor `mycursor`:
+
+``` pre
+FETCH FORWARD 5 FROM mycursor;
+ 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
+```
+
+-- Close the cursor and end the transaction:
+
+``` pre
+CLOSE mycursor;
+COMMIT;
+```
+
+## <a id="topic1__section8"></a>Compatibility
+
+SQL standard allows cursors only in embedded SQL and in modules. HAWQ permits cursors to be used interactively.
+
+The variant of `FETCH` described here returns the data as if it were a `SELECT` result rather than placing it in host variables. Other than this point, `FETCH` is fully upward-compatible with the SQL standard.
+
+The `FETCH` forms involving `FORWARD`, as well as the forms `FETCH` count and `FETCH ALL`, in which `FORWARD` is implicit, are HAWQ extensions. `BACKWARD` is not supported.
+
+The SQL standard allows only `FROM` preceding the cursor name; the option to use `IN` is an extension.
+
+## <a id="topic1__section9"></a>See Also
+
+[DECLARE](DECLARE.html), [CLOSE](CLOSE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/GRANT.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/GRANT.html.md.erb b/markdown/reference/sql/GRANT.html.md.erb
new file mode 100644
index 0000000..1673df5
--- /dev/null
+++ b/markdown/reference/sql/GRANT.html.md.erb
@@ -0,0 +1,180 @@
+---
+title: GRANT
+---
+
+Defines access privileges.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+GRANT { {SELECT | INSERT | UPDATE | DELETE | REFERENCES }
+[,...] | ALL [PRIVILEGES] }
+����ON [TABLE] <tablename> [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT { {USAGE | SELECT | UPDATE} [,...] | ALL [PRIVILEGES] }
+����ON SEQUENCE <sequencename> [, ...]
+����TO { <rolename> | PUBLIC } [, ...] [WITH GRANT OPTION]
+
+GRANT { {CREATE | CONNECT | TEMPORARY | TEMP} [,...] | ALL
+[PRIVILEGES] }
+����ON DATABASE <dbname> [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT { EXECUTE | ALL [PRIVILEGES] }
+����ON FUNCTION <funcname> ( [ [<argmode>] [<argname>] <argtype> [, ...]
+ ] ) [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT { USAGE | ALL [PRIVILEGES] }
+����ON LANGUAGE <langname> [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT { {CREATE | USAGE} [,...] | ALL [PRIVILEGES] }
+����ON SCHEMA <schemaname> [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT { CREATE | ALL [PRIVILEGES] }
+����ON TABLESPACE <tablespacename> [, ...]
+����TO {<rolename> | PUBLIC} [, ...] [WITH GRANT OPTION]
+
+GRANT <parent_role> [, ...]
+����TO <member_role> [, ...] [WITH ADMIN OPTION]
+
+GRANT { SELECT | INSERT | ALL [PRIVILEGES] }
+����ON PROTOCOL <protocolname>
+����TO <username>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+The `GRANT` command has two basic variants: one that grants privileges on a database object (table, view, sequence, database, function, procedural language, schema, or tablespace), and one that grants membership in a role.
+
+**GRANT on Database Objects**
+
+This variant of the `GRANT` command gives specific privileges on a database object to one or more roles. These privileges are added to those already granted, if any.
+
+The key word `PUBLIC` indicates that the privileges are to be granted to all roles, including those that may be created later. `PUBLIC` may be thought of as an implicitly defined group-level role that always includes all roles. Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to `PUBLIC`.
+
+If `WITH GRANT OPTION` is specified, the recipient of the privilege may in turn grant it to others. Without a grant option, the recipient cannot do that. Grant options cannot be granted to `PUBLIC`.
+
+There is no need to grant privileges to the owner of an object (usually the role that created it), as the owner has all privileges by default. The right to drop an object, or to alter its definition in any way is not described by a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. The owner implicitly has all grant options for the object, too.
+
+Depending on the type of object, the initial default privileges may include granting some privileges to `PUBLIC`. The default is no public access for tables, schemas, and tablespaces; `CONNECT` privilege and `TEMP` table creation privilege for databases; `EXECUTE` privilege for functions; and `USAGE` privilege for languages. The object owner may of course revoke these privileges.
+
+**GRANT on Roles**
+
+This variant of the `GRANT` command grants membership in a role to one or more other roles. Membership in a role is significant because it conveys the privileges granted to a role to each of its members.
+
+If `WITH ADMIN OPTION` is specified, the member may in turn grant membership in the role to others, and revoke membership in the role as well. Database superusers can grant or revoke membership in any role to anyone. Roles having `CREATEROLE` privilege can grant or revoke membership in any role that is not a superuser.
+
+Unlike the case with privileges, membership in a role cannot be granted to `PUBLIC`.
+
+## <a id="topic1__section7"></a>Parameters
+
+<dt>SELECT </dt>
+<dd>Allows `SELECT` from any column of the specified table, view, or sequence. Also allows the use of `COPY TO`. For sequences, this privilege also allows the use of the `currval` function.</dd>
+
+<dt>INSERT </dt>
+<dd>Allows `INSERT` of a new row into the specified table. Also allows `COPY FROM`.</dd>
+
+<dt>UPDATE </dt>
+<dd>Allows `UPDATE` of any column of the specified table. `SELECT ... FOR UPDATE` and `SELECT ... FOR SHARE` also require this privilege (as well as the `SELECT` privilege). For sequences, this privilege allows the use of the `nextval` and `setval` functions.</dd>
+
+<dt>DELETE </dt>
+<dd>Allows `DELETE` of a row from the specified table.</dd>
+
+<dt>REFERENCES </dt>
+<dd>This keyword is accepted, although foreign key constraints are currently not supported in HAWQ. To create a foreign key constraint, it is necessary to have this privilege on both the referencing and referenced tables.</dd>
+
+<dt>TRIGGER </dt>
+<dd>Allows the creation of a trigger on the specified table.
+
+**Note:** HAWQ does not support triggers.</dd>
+
+<dt>CREATE </dt>
+<dd>For databases, allows new schemas to be created within the database.
+
+For schemas, allows new objects to be created within the schema. To rename an existing object, you must own the object and have this privilege for the containing schema.
+
+For tablespaces, allows tables and indexes to be created within the tablespace, and allows databases to be created that have the tablespace as their default tablespace. (Note that revoking this privilege will not alter the placement of existing objects.)</dd>
+
+<dt>CONNECT </dt>
+<dd>Allows the user to connect to the specified database. This privilege is checked at connection startup (in addition to checking any restrictions imposed by `pg_hba.conf`).</dd>
+
+<dt>TEMPORARY
+TEMP </dt>
+<dd>Allows temporary tables to be created while using the database.</dd>
+
+<dt>EXECUTE </dt>
+<dd>Allows the use of the specified function and the use of any operators that are implemented on top of the function. This is the only type of privilege that is applicable to functions. (This syntax works for aggregate functions, as well.)</dd>
+
+<dt>USAGE </dt>
+<dd>For procedural languages, allows the use of the specified language for the creation of functions in that language. This is the only type of privilege that is applicable to procedural languages.
+
+For schemas, allows access to objects contained in the specified schema (assuming that the objects' own privilege requirements are also met). Essentially this allows the grantee to look up objects within the schema.
+
+For sequences, this privilege allows the use of the `currval` and `nextval` functions.</dd>
+
+<dt>ALL PRIVILEGES </dt>
+<dd>Grant all of the available privileges at once. The `PRIVILEGES` key word is optional in HAWQ, though it is required by strict SQL.</dd>
+
+<dt>PUBLIC </dt>
+<dd>A special group-level role that denotes that the privileges are to be granted to all roles, including those that may be created later.</dd>
+
+<dt>WITH GRANT OPTION </dt>
+<dd>The recipient of the privilege may in turn grant it to others.</dd>
+
+<dt>WITH ADMIN OPTION </dt>
+<dd>The member of a role may in turn grant membership in the role to others.</dd>
+
+## <a id="topic1__section8"></a>Notes
+
+Database superusers can access all objects regardless of object privilege settings. One exception to this rule is view objects. Access to tables referenced in the view is determined by permissions of the view owner not the current user (even if the current user is a superuser).
+
+If a superuser chooses to issue a `GRANT` or `REVOKE` command, the command is performed as though it were issued by the owner of the affected object. In particular, privileges granted via such a command will appear to have been granted by the object owner. For role membership, the membership appears to have been granted by the containing role itself.
+
+`GRANT` and `REVOKE` can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that holds privileges `WITH GRANT OPTION` on the object. In this case the privileges will be recorded as having been granted by the role that actually owns the object or holds the privileges `WITH GRANT OPTION`.
+
+Granting permission on a table does not automatically extend permissions to any sequences used by the table, including sequences tied to `SERIAL` columns. Permissions on a sequence must be set separately.
+
+HAWQ does not support granting or revoking privileges for individual columns of a table. One possible workaround is to create a view having just the desired columns and then grant privileges to that view.
+
+Use psql's `\z` meta-command to obtain information about existing privileges for an object.
+
+## <a id="topic1__section9"></a>Examples
+
+Grant insert privilege to all roles on table `mytable`:
+
+``` pre
+GRANT INSERT ON mytable TO PUBLIC;
+```
+
+Grant all available privileges to role `sally` on the view `topten`. Note that while the above will indeed grant all privileges if executed by a superuser or the owner of `topten`, when executed by someone else it will only grant those permissions for which the granting role has grant options.
+
+``` pre
+GRANT ALL PRIVILEGES ON topten TO sally;
+```
+
+Grant membership in role `admins` to user `joe`:
+
+``` pre
+GRANT admins TO joe;
+```
+
+## <a id="topic1__section10"></a>Compatibility
+
+The `PRIVILEGES` key word in is required in the SQL standard, but optional in HAWQ. The SQL standard does not support setting the privileges on more than one object per command.
+
+HAWQ allows an object owner to revoke his own ordinary privileges: for example, a table owner can make the table read-only to himself by revoking his own `INSERT` privileges. This is not possible according to the SQL standard. HAWQ treats the owner's privileges as having been granted by the owner to himself; therefore he can revoke them too. In the SQL standard, the owner's privileges are granted by an assumed *system* entity.
+
+The SQL standard allows setting privileges for individual columns within a table.
+
+The SQL standard provides for a `USAGE` privilege on other kinds of objects: character sets, collations, translations, domains.
+
+Privileges on databases, tablespaces, schemas, and languages are HAWQ extensions.
+
+## <a id="topic1__section11"></a>See Also
+
+[REVOKE](REVOKE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/INSERT.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/INSERT.html.md.erb b/markdown/reference/sql/INSERT.html.md.erb
new file mode 100644
index 0000000..d23a2aa
--- /dev/null
+++ b/markdown/reference/sql/INSERT.html.md.erb
@@ -0,0 +1,111 @@
+---
+title: INSERT
+---
+
+Creates new rows in a table.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+INSERT INTO <table> [( <column> [, ...] )]
+���{DEFAULT VALUES | VALUES ( {<expression> | DEFAULT} [, ...] )
+ [, ...] | <query>}
+```
+
+## <a id="topic1__section3"></a>Description
+
+`INSERT` inserts new rows into a table. One can insert one or more rows specified by value expressions, or zero or more rows resulting from a query.
+
+The target column names may be listed in any order. If no list of column names is given at all, the default is the columns of the table in their declared order. The values supplied by the `VALUES` clause or query are associated with the explicit or implicit column list left-to-right.
+
+Each column not present in the explicit or implicit column list will be filled with a default value, either its declared default value or null if there is no default.
+
+If the expression for any column is not of the correct data type, automatic type conversion will be attempted.
+
+You must have `INSERT` privilege on a table in order to insert into it.
+
+**Note:** HAWQ supports 127 concurrent inserts currently.
+
+**Outputs**
+On successful completion, an `INSERT` command returns a command tag of the form:
+
+``` pre
+INSERT oid
+ count
+```
+
+The *count* is the number of rows inserted. If count is exactly one, and the target table has OIDs, then *oid* is the OID assigned to the inserted row. Otherwise *oid* is zero.
+
+## <a id="topic1__section5"></a>Parameters
+
+<dt> \<table\> </dt>
+<dd>The name (optionally schema-qualified) of an existing table.</dd>
+
+<dt> \<column\> </dt>
+<dd>The name of a column in table. The column name can be qualified with a subfield name or array subscript, if needed. (Inserting into only some fields of a composite column leaves the other fields null.)</dd>
+
+<dt>DEFAULT VALUES </dt>
+<dd>All columns will be filled with their default values.</dd>
+
+<dt> \<expression\> </dt>
+<dd>An expression or value to assign to the corresponding column.</dd>
+
+<dt>DEFAULT </dt>
+<dd>The corresponding column will be filled with its default value.</dd>
+
+<dt> \<query\> </dt>
+<dd>A query (`SELECT` statement) that supplies the rows to be inserted. Refer to the [SELECT](SELECT.html) statement for a description of the syntax.</dd>
+
+## <a id="topic1__section7"></a>Examples
+
+Insert a single row into table `films`:
+
+``` pre
+INSERT INTO films VALUES ('UA502', 'Bananas', 105,
+'1971-07-13', 'Comedy', '82 minutes');
+```
+
+In this example, the `length` column is omitted and therefore it will have the default value:
+
+``` pre
+INSERT INTO films (code, title, did, date_prod, kind) VALUES
+('T_601', 'Yojimbo', 106, '1961-06-16', 'Drama');
+```
+
+This example uses the `DEFAULT` clause for the `date_prod` column rather than specifying a value:
+
+``` pre
+INSERT INTO films VALUES ('UA502', 'Bananas', 105, DEFAULT,
+'Comedy', '82 minutes');
+```
+
+To insert a row consisting entirely of default values:
+
+``` pre
+INSERT INTO films DEFAULT VALUES;
+```
+
+To insert multiple rows using the multirow `VALUES` syntax:
+
+``` pre
+INSERT INTO films (code, title, did, date_prod, kind) VALUES
+ ('B6717', 'Tampopo', 110, '1985-02-10', 'Comedy'),
+ ('HG120', 'The Dinner Game', 140, DEFAULT, 'Comedy');
+```
+
+This example inserts some rows into table `films` from a table `tmp_films` with the same column layout as `films`:
+
+``` pre
+INSERT INTO films SELECT * FROM tmp_films WHERE date_prod <
+'2004-05-07';
+```
+
+## <a id="topic1__section8"></a>Compatibility
+
+`INSERT` conforms to the SQL standard. The case in which a column name list is omitted, but not all the columns are filled from the `VALUES` clause or query, is disallowed by the standard.
+
+Possible limitations of the *query* clause are documented under `SELECT`.
+
+## <a id="topic1__section9"></a>See Also
+
+[COPY](COPY.html), [SELECT](SELECT.html), [CREATE EXTERNAL TABLE](CREATE-EXTERNAL-TABLE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/PREPARE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/PREPARE.html.md.erb b/markdown/reference/sql/PREPARE.html.md.erb
new file mode 100644
index 0000000..c633f14
--- /dev/null
+++ b/markdown/reference/sql/PREPARE.html.md.erb
@@ -0,0 +1,67 @@
+---
+title: PREPARE
+---
+
+Prepare a statement for execution.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+PREPARE <name> [ (<datatype> [, ...] ) ] AS <statement>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`PREPARE` creates a prepared statement, possibly with unbound parameters. A prepared statement is a server-side object that can be used to optimize performance. A prepared statement may be subsequently executed with a binding for its parameters. HAWQ may choose to replan the query for different executions of the same prepared statement.
+
+Prepared statements can take parameters: values that are substituted into the statement when it is executed. When creating the prepared statement, refer to parameters by position, using `$1`, `$2`, etc. A corresponding list of parameter data types can optionally be specified. When a parameter's data type is not specified or is declared as unknown, the type is inferred from the context in which the parameter is used (if possible). When executing the statement, specify the actual values for these parameters in the `EXECUTE` statement.
+
+Prepared statements only last for the duration of the current database session. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again. This also means that a single prepared statement cannot be used by multiple simultaneous database clients; however, each client can create their own prepared statement to use. The prepared statement can be manually cleaned up using the [DEALLOCATE](DEALLOCATE.html) command.
+
+Prepared statements have the largest performance advantage when a single session is being used to execute a large number of similar statements. The performance difference will be particularly significant if the statements are complex to plan or rewrite, for example, if the query involves a join of many tables or requires the application of several rules. If the statement is relatively simple to plan and rewrite but relatively expensive to execute, the performance advantage of prepared statements will be less noticeable.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt> \<name\> </dt>
+<dd>An arbitrary name given to this particular prepared statement. It must be unique within a single session and is subsequently used to execute or deallocate a previously prepared statement.</dd>
+
+<dt> \<datatype\> </dt>
+<dd>The data type of a parameter to the prepared statement. If the data type of a particular parameter is unspecified or is specified as unknown, it will be inferred from the context in which the parameter is used. To refer to the parameters in the prepared statement itself, use `$1`, `$2`, etc.</dd>
+
+<dt> \<statement\> </dt>
+<dd>Any `SELECT`, `INSERT`, or `VALUES` statement.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+In some situations, the query plan produced for a prepared statement will be inferior to the query plan that would have been chosen if the statement had been submitted and executed normally. This is because when the statement is planned and the planner attempts to determine the optimal query plan, the actual values of any parameters specified in the statement are unavailable. HAWQ collects statistics on the distribution of data in the table, and can use constant values in a statement to make guesses about the likely result of executing the statement. Since this data is unavailable when planning prepared statements with parameters, the chosen plan may be suboptimal. To examine the query plan HAWQ has chosen for a prepared statement, use `EXPLAIN`.
+
+For more information on query planning and the statistics collected by HAWQ for that purpose, see the `ANALYZE` documentation.
+
+You can see all available prepared statements of a session by querying the `pg_prepared_statements` system view.
+
+## <a id="topic1__section6"></a>Examples
+
+Create a prepared statement for an `INSERT` statement, and then execute it:
+
+``` pre
+PREPARE fooplan (int, text, bool, numeric) AS INSERT INTO
+foo VALUES($1, $2, $3, $4);
+EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
+```
+
+Create a prepared statement for a `SELECT` statement, and then execute it. Note that the data type of the second parameter is not specified, so it is inferred from the context in which `$2` is used:
+
+``` pre
+PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l
+WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2;
+EXECUTE usrrptplan(1, current_date);
+```
+
+## <a id="topic1__section7"></a>Compatibility
+
+The SQL standard includes a `PREPARE` statement, but it is only for use in embedded SQL. This version of the `PREPARE` statement also uses a somewhat different syntax.
+
+## <a id="topic1__section8"></a>See Also
+
+[EXECUTE](EXECUTE.html), [DEALLOCATE](DEALLOCATE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/REASSIGN-OWNED.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/REASSIGN-OWNED.html.md.erb b/markdown/reference/sql/REASSIGN-OWNED.html.md.erb
new file mode 100644
index 0000000..c037bfe
--- /dev/null
+++ b/markdown/reference/sql/REASSIGN-OWNED.html.md.erb
@@ -0,0 +1,48 @@
+---
+title: REASSIGN OWNED
+---
+
+Changes the ownership of database objects owned by a database role.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+REASSIGN OWNED BY <old_role> [, ...] TO <new_role>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`REASSIGN OWNED` reassigns all the objects in the current database that are owned by \<old\_role\> to \<new\_role\>. Note that it does not change the ownership of the database itself.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt> \<old\_role\> </dt>
+<dd>The name of a role. The ownership of all the objects in the current database owned by this role will be reassigned to \<new\_role\>.</dd>
+
+<dt> \<new\_role\> </dt>
+<dd>The name of the role that will be made the new owner of the affected objects.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+`REASSIGN OWNED` is often used to prepare for the removal of one or more roles. Because `REASSIGN OWNED` only affects the objects in the current database, it is usually necessary to execute this command in each database that contains objects owned by a role that is to be removed.
+
+The `DROP OWNED` command is an alternative that drops all the database objects owned by one or more roles.
+
+The `REASSIGN OWNED` command does not affect the privileges granted to the old roles in objects that are not owned by them. Use `DROP OWNED` to revoke those privileges.
+
+## <a id="topic1__section6"></a>Examples
+
+Reassign any database objects owned by the role named `sally` and `bob` to `admin`;
+
+``` pre
+REASSIGN OWNED BY sally, bob TO admin;
+```
+
+## <a id="topic1__section7"></a>Compatibility
+
+The `REASSIGN OWNED` statement is a HAWQ extension.
+
+## <a id="topic1__section8"></a>See Also
+
+[DROP OWNED](DROP-OWNED.html), [DROP ROLE](DROP-ROLE.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/RELEASE-SAVEPOINT.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/RELEASE-SAVEPOINT.html.md.erb b/markdown/reference/sql/RELEASE-SAVEPOINT.html.md.erb
new file mode 100644
index 0000000..ca25d9e
--- /dev/null
+++ b/markdown/reference/sql/RELEASE-SAVEPOINT.html.md.erb
@@ -0,0 +1,48 @@
+---
+title: RELEASE SAVEPOINT
+---
+
+Destroys a previously defined savepoint.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+RELEASE [SAVEPOINT] <savepoint_name>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`RELEASE SAVEPOINT` destroys a savepoint previously defined in the current transaction.
+
+Destroying a savepoint makes it unavailable as a rollback point, but it has no other user visible behavior. It does not undo the effects of commands executed after the savepoint was established. (To do that, see [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html).) Destroying a savepoint when it is no longer needed may allow the system to reclaim some resources earlier than transaction end.
+
+`RELEASE SAVEPOINT` also destroys all savepoints that were established *after* the named savepoint was established.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt> \<savepoint\_name\> </dt>
+<dd>The name of the savepoint to destroy.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+To establish and later destroy a savepoint:
+
+``` pre
+BEGIN;
+ INSERT INTO table1 VALUES (3);
+ SAVEPOINT my_savepoint;
+ INSERT INTO table1 VALUES (4);
+ RELEASE SAVEPOINT my_savepoint;
+COMMIT;
+```
+
+The above transaction will insert both 3 and 4.
+
+## <a id="topic1__section6"></a>Compatibility
+
+This command conforms to the SQL standard. The standard specifies that the key word `SAVEPOINT` is mandatory, but HAWQ allows it to be omitted.
+
+## <a id="topic1__section7"></a>See Also
+
+[BEGIN](BEGIN.html), [SAVEPOINT](SAVEPOINT.html), [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html), [COMMIT](COMMIT.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/RESET.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/RESET.html.md.erb b/markdown/reference/sql/RESET.html.md.erb
new file mode 100644
index 0000000..cb04d32
--- /dev/null
+++ b/markdown/reference/sql/RESET.html.md.erb
@@ -0,0 +1,45 @@
+---
+title: RESET
+---
+
+Restores the value of a system configuration parameter to the default value.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+RESET <configuration_parameter>
+
+RESET ALL
+```
+
+## <a id="topic1__section3"></a>Description
+
+`RESET` restores system configuration parameters to their default values. `RESET` is an alternative spelling for `SET configuration_parameter TO DEFAULT`.
+
+The default value is defined as the value that the parameter would have had, had no `SET` ever been issued for it in the current session. The actual source of this value might be a compiled-in default, the master `hawq-site.xml` configuration file, command-line options, or per-database or per-user default settings.
+
+See [Server Configuration Parameter Reference](../HAWQSiteConfig.html) for more information.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt> \<configuration\_parameter\> </dt>
+<dd>The name of a system configuration parameter. See [Server Configuration Parameter Reference](../HAWQSiteConfig.html) for a list of configuration parameters.</dd>
+
+<dt>ALL </dt>
+<dd>Resets all settable configuration parameters to their default values.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Set the `hawq_rm_stmt_vseg_memory` configuration parameter to its default value:
+
+``` sql
+RESET hawq_rm_stmt_vseg_memory;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+`RESET` is a HAWQ extension.
+
+## <a id="topic1__section7"></a>See Also
+
+[SET](SET.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/REVOKE.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/REVOKE.html.md.erb b/markdown/reference/sql/REVOKE.html.md.erb
new file mode 100644
index 0000000..cad809a
--- /dev/null
+++ b/markdown/reference/sql/REVOKE.html.md.erb
@@ -0,0 +1,101 @@
+---
+title: REVOKE
+---
+
+Removes access privileges.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+REVOKE [GRANT OPTION FOR] { {SELECT | INSERT | UPDATE | DELETE
+�������| REFERENCES | TRUNCATE } [,...] | ALL [PRIVILEGES] }
+�������ON [TABLE] <tablename> [, ...]
+�������FROM {<rolename> | PUBLIC} [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [GRANT OPTION FOR] { {USAGE | SELECT | UPDATE} [,...]
+�������| ALL [PRIVILEGES] }
+�������ON SEQUENCE <sequencename> [, ...]
+�������FROM { <rolename> | PUBLIC } [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [GRANT OPTION FOR] { {CREATE | CONNECT
+�������| TEMPORARY | TEMP} [,...] | ALL [PRIVILEGES] }
+�������ON DATABASE <dbname> [, ...]
+�������FROM {<rolename> | PUBLIC} [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [GRANT OPTION FOR] {EXECUTE | ALL [PRIVILEGES]}
+�������ON FUNCTION <funcname> ( [[<argmode>] [<argname>] <argtype>
+������������������������������[, ...]] ) [, ...]
+�������FROM {<rolename> | PUBLIC} [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [GRANT OPTION FOR] {USAGE | ALL [PRIVILEGES]}
+�������ON LANGUAGE <langname> [, ...]
+�������FROM {<rolename> | PUBLIC} [, ...]
+�������[ CASCADE | RESTRICT ]
+
+REVOKE [GRANT OPTION FOR] { {CREATE | USAGE} [,...]
+�������| ALL [PRIVILEGES] }
+�������ON SCHEMA <schemaname> [, ...]
+�������FROM {<rolename> | PUBLIC} [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [GRANT OPTION FOR] { CREATE | ALL [PRIVILEGES] }
+�������ON TABLESPACE <tablespacename> [, ...]
+�������FROM { <rolename> | PUBLIC } [, ...]
+�������[CASCADE | RESTRICT]
+
+REVOKE [ADMIN OPTION FOR] <parent_role> [, ...]
+�������FROM <member_role> [, ...]
+�������[CASCADE | RESTRICT]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`REVOKE` command revokes previously granted privileges from one or more roles. The key word `PUBLIC` refers to the implicitly defined group of all roles.
+
+See the description of the [GRANT](GRANT.html) command for the meaning of the privilege types.
+
+Note that any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to `PUBLIC`. Thus, for example, revoking `SELECT` privilege from `PUBLIC` does not necessarily mean that all roles have lost `SELECT` privilege on the object: those who have it granted directly or via another role will still have it.
+
+If `GRANT OPTION FOR` is specified, only the grant option for the privilege is revoked, not the privilege itself. Otherwise, both the privilege and the grant option are revoked.
+
+If a role holds a privilege with grant option and has granted it to other roles then the privileges held by those other roles are called dependent privileges. If the privilege or the grant option held by the first role is being revoked and dependent privileges exist, those dependent privileges are also revoked if `CASCADE` is specified, else the revoke action will fail. This recursive revocation only affects privileges that were granted through a chain of roles that is traceable to the role that is the subject of this `REVOKE` command. Thus, the affected roles may effectively keep the privilege if it was also granted through other roles.
+
+When revoking membership in a role, `GRANT OPTION` is instead called `ADMIN OPTION`, but the behavior is similar.
+
+## <a id="topic1__section4"></a>Parameters
+
+See [GRANT](GRANT.html).
+
+## <a id="topic1__section5"></a>Examples
+
+Revoke insert privilege for the public on table `films`:
+
+``` sql
+REVOKE INSERT ON films FROM PUBLIC;
+```
+
+Revoke all privileges from role `sally` on view `topten`. Note that this actually means revoke all privileges that the current role granted (if not a superuser).
+
+``` sql
+REVOKE ALL PRIVILEGES ON topten FROM sally;
+```
+
+Revoke membership in role `admins` from user `joe`:
+
+``` sql
+REVOKE admins FROM joe;
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+The compatibility notes of the [GRANT](GRANT.html) command also apply to `REVOKE`.
+
+Either `RESTRICT` or `CASCADE` is required according to the standard, but HAWQ assumes `RESTRICT` by default.
+
+## <a id="topic1__section7"></a>See Also
+
+[GRANT](GRANT.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/ROLLBACK-TO-SAVEPOINT.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/ROLLBACK-TO-SAVEPOINT.html.md.erb b/markdown/reference/sql/ROLLBACK-TO-SAVEPOINT.html.md.erb
new file mode 100644
index 0000000..33c771b
--- /dev/null
+++ b/markdown/reference/sql/ROLLBACK-TO-SAVEPOINT.html.md.erb
@@ -0,0 +1,77 @@
+---
+title: ROLLBACK TO SAVEPOINT
+---
+
+Rolls back the current transaction to a savepoint.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+ROLLBACK [WORK | TRANSACTION] TO [SAVEPOINT] <savepoint_name>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+This command will roll back all commands that were executed after the savepoint was established. The savepoint remains valid and can be rolled back to again later, if needed.
+
+`ROLLBACK TO SAVEPOINT` implicitly destroys all savepoints that were established after the named savepoint.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>WORK
+TRANSACTION </dt>
+<dd>Optional key words. They have no effect.</dd>
+
+<dt> \<savepoint\_name\> </dt>
+<dd>The name of a savepoint to roll back to.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+Use `RELEASE SAVEPOINT` to destroy a savepoint without discarding the effects of commands executed after it was established.
+
+Specifying a savepoint name that has not been established is an error.
+
+Cursors have somewhat non-transactional behavior with respect to savepoints. Any cursor that is opened inside a savepoint will be closed when the savepoint is rolled back. If a previously opened cursor is affected by a `FETCH` command inside a savepoint that is later rolled back, the cursor position remains at the position that `FETCH` left it pointing to (that is, `FETCH` is not rolled back). Closing a cursor is not undone by rolling back, either. A cursor whose execution causes a transaction to abort is put in a can't-execute state, so while the transaction can be restored using `ROLLBACK TO SAVEPOINT`, the cursor can no longer be used.
+
+## <a id="topic1__section6"></a>Examples
+
+To undo the effects of the commands executed after `my_savepoint` was established:
+
+``` sql
+ROLLBACK TO SAVEPOINT my_savepoint;
+```
+
+Cursor positions are not affected by a savepoint rollback:
+
+``` sql
+BEGIN;
+DECLARE foo CURSOR FOR SELECT 1 UNION SELECT 2;
+SAVEPOINT foo;
+FETCH 1 FROM foo;
+```
+``` pre
+column
+----------
+ 1
+```
+``` sql
+ROLLBACK TO SAVEPOINT foo;
+FETCH 1 FROM foo;
+```
+``` pre
+column
+----------
+ 2
+```
+``` sql
+COMMIT;
+```
+
+## <a id="topic1__section7"></a>Compatibility
+
+The SQL standard specifies that the key word `SAVEPOINT` is mandatory, but HAWQ (and Oracle) allow it to be omitted. SQL allows only `WORK`, not `TRANSACTION`, as a stopword after `ROLLBACK`. Also, SQL has an optional clause `AND [NO] CHAIN` which is not currently supported by HAWQ. Otherwise, this command conforms to the SQL standard.
+
+## <a id="topic1__section8"></a>See Also
+
+[BEGIN](BEGIN.html), [COMMIT](COMMIT.html), [SAVEPOINT](SAVEPOINT.html), [RELEASE SAVEPOINT](RELEASE-SAVEPOINT.html), [ROLLBACK](ROLLBACK.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/ROLLBACK.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/ROLLBACK.html.md.erb b/markdown/reference/sql/ROLLBACK.html.md.erb
new file mode 100644
index 0000000..eb1345d
--- /dev/null
+++ b/markdown/reference/sql/ROLLBACK.html.md.erb
@@ -0,0 +1,43 @@
+---
+title: ROLLBACK
+---
+
+Aborts the current transaction.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+ROLLBACK [WORK | TRANSACTION]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`ROLLBACK` rolls back the current transaction and causes all the updates made by the transaction to be discarded.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt>WORK
+TRANSACTION </dt>
+<dd>Optional key words. They have no effect.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+Use `COMMIT` to successfully end the current transaction.
+
+Issuing `ROLLBACK` when not inside a transaction does no harm, but it will provoke a warning message.
+
+## <a id="topic1__section6"></a>Examples
+
+To discard all changes made in the current transaction:
+
+``` sql
+ROLLBACK;
+```
+
+## <a id="topic1__section7"></a>Compatibility
+
+The SQL standard only specifies the two forms `ROLLBACK` and `ROLLBACK WORK`. Otherwise, this command is fully conforming.
+
+## <a id="topic1__section8"></a>See Also
+
+[BEGIN](BEGIN.html), [COMMIT](COMMIT.html), [SAVEPOINT](SAVEPOINT.html), [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/SAVEPOINT.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/SAVEPOINT.html.md.erb b/markdown/reference/sql/SAVEPOINT.html.md.erb
new file mode 100644
index 0000000..c2f6917
--- /dev/null
+++ b/markdown/reference/sql/SAVEPOINT.html.md.erb
@@ -0,0 +1,66 @@
+---
+title: SAVEPOINT
+---
+
+Defines a new savepoint within the current transaction.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+SAVEPOINT <savepoint_name>
+
+```
+
+## <a id="topic1__section3"></a>Description
+
+`SAVEPOINT` establishes a new savepoint within the current transaction.
+
+A savepoint is a special mark inside a transaction that allows all commands that are executed after it was established to be rolled back, restoring the transaction state to what it was at the time of the savepoint.
+
+## <a id="topic1__section4"></a>Parameters
+
+<dt> \<savepoint\_name\> </dt>
+<dd>The name of the new savepoint.</dd>
+
+## <a id="topic1__section5"></a>Notes
+
+Use [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html) to rollback to a savepoint. Use [RELEASE SAVEPOINT](RELEASE-SAVEPOINT.html) to destroy a savepoint, keeping the effects of commands executed after it was established.
+
+Savepoints can only be established when inside a transaction block. There can be multiple savepoints defined within a transaction.
+
+## <a id="topic1__section6"></a>Examples
+
+To establish a savepoint and later undo the effects of all commands executed after it was established:
+
+``` pre
+BEGIN;
+ INSERT INTO table1 VALUES (1);
+ SAVEPOINT my_savepoint;
+ INSERT INTO table1 VALUES (2);
+ ROLLBACK TO SAVEPOINT my_savepoint;
+ INSERT INTO table1 VALUES (3);
+COMMIT;
+```
+
+The above transaction will insert the values 1 and 3, but not 2.
+
+To establish and later destroy a savepoint:
+
+``` pre
+BEGIN;
+ INSERT INTO table1 VALUES (3);
+ SAVEPOINT my_savepoint;
+ INSERT INTO table1 VALUES (4);
+ RELEASE SAVEPOINT my_savepoint;
+COMMIT;
+```
+
+The above transaction will insert both 3 and 4.
+
+## <a id="topic1__section7"></a>Compatibility
+
+SQL requires a savepoint to be destroyed automatically when another savepoint with the same name is established. In HAWQ, the old savepoint is kept, though only the more recent one will be used when rolling back or releasing. (Releasing the newer savepoint will cause the older one to again become accessible to [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html) and [RELEASE SAVEPOINT](RELEASE-SAVEPOINT.html).) Otherwise, `SAVEPOINT` is fully SQL conforming.
+
+## <a id="topic1__section8"></a>See Also
+
+[BEGIN](BEGIN.html), [COMMIT](COMMIT.html), [ROLLBACK](ROLLBACK.html), [RELEASE SAVEPOINT](RELEASE-SAVEPOINT.html), [ROLLBACK TO SAVEPOINT](ROLLBACK-TO-SAVEPOINT.html)
http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/de1e2e07/markdown/reference/sql/SELECT-INTO.html.md.erb
----------------------------------------------------------------------
diff --git a/markdown/reference/sql/SELECT-INTO.html.md.erb b/markdown/reference/sql/SELECT-INTO.html.md.erb
new file mode 100644
index 0000000..524a5f1
--- /dev/null
+++ b/markdown/reference/sql/SELECT-INTO.html.md.erb
@@ -0,0 +1,55 @@
+---
+title: SELECT INTO
+---
+
+Defines a new table from the results of a query.
+
+## <a id="topic1__section2"></a>Synopsis
+
+``` pre
+SELECT [ALL | DISTINCT [ON ( <expression> [, ...] )]]
+ * | <expression> [AS <output_name>] [, ...]
+ INTO [TEMPORARY | TEMP] [TABLE] <new_table>
+ [FROM <from_item> [, ...]]
+ [WHERE <condition>]
+ [GROUP BY <expression> [, ...]]
+ [HAVING <condition> [, ...]]
+ [{UNION | INTERSECT | EXCEPT} [ALL] <select>]
+ [ORDER BY <expression> [ASC | DESC | USING <operator>] [, ...]]
+ [LIMIT {<count> | ALL}]
+ [OFFSET <start>]
+ [FOR {UPDATE | SHARE} [OF <table_name> [, ...]] [NOWAIT]
+ [...]]
+```
+
+## <a id="topic1__section3"></a>Description
+
+`SELECT INTO` creates a new table and fills it with data computed by a query. The data is not returned to the client, as it is with a normal `SELECT`. The new table's columns have the names and data types associated with the output columns of the `SELECT`. Data is always distributed randomly.
+
+## <a id="topic1__section4"></a>Parameters
+
+The majority of parameters for `SELECT INTO` are the same as [SELECT](SELECT.html).
+
+<dt>TEMPORARY,
+TEMP </dt>
+<dd>If specified, the table is created as a temporary table.</dd>
+
+<dt> \<new\_table\> </dt>
+<dd>The name (optionally schema-qualified) of the table to be created.</dd>
+
+## <a id="topic1__section5"></a>Examples
+
+Create a new table `films_recent` consisting of only recent entries from the table `films`:
+
+``` sql
+SELECT * INTO films_recent FROM films WHERE date_prod >=
+'2006-01-01';
+```
+
+## <a id="topic1__section6"></a>Compatibility
+
+The SQL standard uses `SELECT INTO` to represent selecting values into scalar variables of a host program, rather than creating a new table. The HAWQ usage of `SELECT INTO` to represent table creation is historical. It is best to use [CREATE TABLE AS](CREATE-TABLE-AS.html) for this purpose in new applications.
+
+## <a id="topic1__section7"></a>See Also
+
+[SELECT](SELECT.html), [CREATE TABLE AS](CREATE-TABLE-AS.html)