Fix incorrect description of rowtype variable declarations. Eventually
authorTom Lane
Wed, 2 Jan 2002 00:41:26 +0000 (00:41 +0000)
committerTom Lane
Wed, 2 Jan 2002 00:41:26 +0000 (00:41 +0000)
(IMHO) the code should be fixed to do what the documentation formerly
claimed, and then revert this change.

doc/src/sgml/plsql.sgml

index a7c9b12c1b021458e1c592144cd4465eb7981ef9..7ec861d850578ca55fdfcfb4a4ee57900e5a7416 100644 (file)
@@ -1,5 +1,5 @@
 
 
  
@@ -457,20 +457,27 @@ END;
 
     
 
-name table-datatype>;
+name tablename%ROWTYPE>;
 
     
 
    
-    A variable declared with a composite type (referenced by the name of
-    the table that defines that type) is called a row
-    variable.  Such a variable can hold a whole row of a SELECT or FOR
+    A variable of a composite type is called a row
+    variable (or rowtype variable).  Such a variable can hold a
+    whole row of a SELECT or FOR
     query result, so long as that query's column set matches the declared
-    rowtype of the variable.  The individual fields of the row value are
+    type of the variable.  The individual fields of the row value are
     accessed using the usual dot notation, for example
     rowvar.field.
    
 
+   
+    Presently, a row variable can only be declared using the
+    %ROWTYPE notation; although one might expect a
+    bare table name to work as a type declaration, it won't be accepted
+    within PL/pgSQL functions.
+   
+
    
     Parameters to a function can be
     composite types (complete table rows). In that case, the
@@ -563,9 +570,7 @@ user_id   users.user_id%TYPE;
     %ROWTYPE provides the composite data type corresponding
     to a whole row of the specified table.
     table must be an existing
-    table or view name of the database.  A row variable declared
-    in this way acts the same as a row variable explicitly declared using
-    the same composite (row) datatype.
+    table or view name of the database.
         
 
 
@@ -616,6 +621,15 @@ RENAME id TO user_id;
 RENAME this_var TO that_var;
 
      
+
+    
+    
+     RENAME appears to be broken as of PostgreSQL 7.2.  Fixing this is
+     of low priority, since ALIAS covers most of the practical uses of
+     RENAME.
+    
+    
+