Add a tip showing how functions on composite types can be used to

emulate computed fields.  I suppose this is why the Berkeley boys made
it work that way in the first place, but the docs never said so anyplace.

diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 534ba4c08fe0961eb7d339e228264bef64e114af..bd70eb016b393a86b3a43c5589a707b7e7a559f4 100644 (file)
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -450,6 +450,31 @@ SELECT name(emp) AS youngster FROM emp WHERE age(emp) < 30;
 
     
 
+    
+     
+      The equivalence between functional notation and attribute notation
+      makes it possible to use functions on composite types to emulate
+      computed fields.
+      
+       computed field
+      
+      
+       field
+       computed
+      
+      For example, using the previous definition
+      for double_salary(emp), we can write
+
+
+SELECT emp.name, emp.double_salary FROM emp;
+
+
+      An application using this wouldn't need to be directly aware that
+      double_salary isn't a real column of the table.
+      (You can also emulate computed fields with views.)
+     
+    
+
     
      Another way to use a function returning a row result is to pass the
      result to another function that accepts the correct row type as input: