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 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.93 2005/01/07 22:40:46 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.94 2005/01/07 23:08:44 tgl Exp $
 -->
 
  <sect1 id="xfunc">
@@ -450,6 +450,31 @@ SELECT name(emp) AS youngster FROM emp WHERE age(emp) &lt; 30;
 </screen>
     </para>
 
+    <tip>
+     <para>
+      The equivalence between functional notation and attribute notation
+      makes it possible to use functions on composite types to emulate
+      <quote>computed fields</>.
+      <indexterm>
+       <primary>computed field</primary>
+      </indexterm>
+      <indexterm>
+       <primary>field</primary>
+       <secondary>computed</secondary>
+      </indexterm>
+      For example, using the previous definition
+      for <literal>double_salary(emp)</>, we can write
+
+<screen>
+SELECT emp.name, emp.double_salary FROM emp;
+</screen>
+
+      An application using this wouldn't need to be directly aware that
+      <literal>double_salary</> isn't a real column of the table.
+      (You can also emulate computed fields with views.)
+     </para>
+    </tip>
+
     <para>
      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: