From: | John Gage <jsmgage(at)numericable(dot)fr> |
---|---|
To: | pgsql-docs(at)postgresql(dot)org |
Subject: | Adding a crucial element to an example |
Date: | 2010-07-23 10:02:02 |
Message-ID: | 9A88E54D-2CF7-403F-A0D8-35B9ECDC7103@numericable.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
The examples in the documentation are the most valuable part.
In this section, you create the table for the example, but you do not
populate it, although the example select statements are against the
phantom population that has not been inserted.
I suggest strongly including the minimal code necessary to populate
the table, so that the user doesn't have to populate it himself. Call
me lazy, but I did go into pgAdmin and insert values after creating a
primary key.
Cutting and pasting examples and then playing around with them is by
far, by far the most productive way to learn the system.
John
35.4.2. SQL Functions on Composite Types
When writing functions with arguments of composite types, we must not
only specify which argument we want (as we did above with $1 and $2)
but also the desired attribute (field) of that argument. For example,
suppose that emp is a table containing employee data, and therefore
also the name of the composite type of each row of the table. Here is
a function double_salary that computes what someone's salary would be
if it were doubled:
CREATE TABLE emp ( name text, salary numeric, age integer, cubicle
point );
CREATE FUNCTION double_salary(emp) RETURNS numeric AS $$
SELECT $1.salary * 2 AS salary;
$$ LANGUAGE SQL;
SELECT name, double_salary(emp.*) AS dream FROM emp WHERE emp.cubicle
~= point '(2,1)';
name | dream
------+-------
Bill | 8400
From | Date | Subject | |
---|---|---|---|
Next Message | Craig James | 2010-07-23 21:47:23 | Re: Using more tha one index per table |
Previous Message | Torsten Zühlsdorff | 2010-07-23 09:22:18 | Re: Using more tha one index per table |