Skip to content

P
Postgres FD Implementation
Commit 74bbe809 authored by Peter Eisentraut's avatar Peter Eisentraut
Browse files
Options

Replace some oldish, non-SQL'ish elements with more standard forms. (cast 

syntax, type names, function names, etc.)
parent 84532086
Expand all Show whitespace changes
Inline Side-by-side
Showing with 119 additions and 138 deletions
doc/src/sgml/dfunc.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.12 2001/01/12 22:15:32 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.13 2001/01/20 20:59:28 petere Exp $
-->
<sect2 id="dfunc">
......@@ -20,7 +20,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.12 2001/01/12 22:15:32 peter
In addition, the <productname>PostgreSQL</productname> source code
contains several working examples in the
<filename>contrib</filename> directory. If you rely on these
examples you will make your modules dependent on the documentation
examples you will make your modules dependent on the availability
of the <productname>PostgreSQL</productname> source code, however.
</para>
......@@ -29,8 +29,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.12 2001/01/12 22:15:32 peter
executables: first the source files are compiled into object files,
then the object files are linked together. The object files need to
be created as <firstterm>position-independent code</firstterm>
(<acronym>PIC</acronym>), which conceptually means that it can be
placed at an arbitrary location in memory when it is loaded by the
(<acronym>PIC</acronym>), which conceptually means that they can be
placed at an arbitrary location in memory when they are loaded by the
executable. (Object files intended for executables are not compiled
that way.) The command to link a shared library contains special
flags to distinguish it from linking an executable. --- At least
......
doc/src/sgml/func.sgml
View file @ 74bbe809
This diff is collapsed.
doc/src/sgml/libpq++.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.23 2001/01/13 23:58:55 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.24 2001/01/20 20:59:28 petere Exp $
-->
<chapter id="libpqplusplus">
......@@ -735,7 +735,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.23 2001/01/13 23:58:
<programlisting>
PgDatabase data;
data.Exec("create table foo (a int4, b char(16), d float8)");
data.Exec("create table foo (a int4, b char(16), d double precision)");
data.Exec("copy foo from stdin");
data.PutLine("3\tHello World\t4.5\n");
data.PutLine("4\tGoodbye World\t7.11\n");
......
doc/src/sgml/libpq.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.56 2001/01/18 07:18:39 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.57 2001/01/20 20:59:28 petere Exp $
-->
<chapter id="libpq-chapter">
......@@ -1685,7 +1685,7 @@ int PQendcopy(PGconn *conn);
As an example:
<programlisting>
PQexec(conn, "create table foo (a int4, b char(16), d float8)");
PQexec(conn, "create table foo (a int4, b char(16), d double precision)");
PQexec(conn, "copy foo from stdin");
PQputline(conn, "3\thello world\t4.5\n");
PQputline(conn,"4\tgoodbye world\t7.11\n");
......@@ -2226,13 +2226,11 @@ main()
*
* populate a database by doing the following:
*
* CREATE TABLE test1 (i int4, d float4, p polygon);
* CREATE TABLE test1 (i int4, d real, p polygon);
*
* INSERT INTO test1 values (1, 3.567, '(3.0, 4.0, 1.0,
* 2.0)'::polygon);
* INSERT INTO test1 values (1, 3.567, polygon '(3.0, 4.0, 1.0, 2.0)');
*
* INSERT INTO test1 values (2, 89.05, '(4.0, 3.0, 2.0,
* 1.0)'::polygon);
* INSERT INTO test1 values (2, 89.05, polygon '(4.0, 3.0, 2.0, 1.0)');
*
* the expected output is:
*
......
doc/src/sgml/odbc.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.20 2000/12/22 21:51:58 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.21 2001/01/20 20:59:28 petere Exp $
-->
<chapter id="odbc">
......@@ -290,14 +290,6 @@ InstallDir = /opt/applix/axdata/axshlib
</para>
</tip>
<!--
<Para>
<Tip>
<Para>
The <productname>Postgres</productname> datetime type will break MS Access.
</Para>
</Tip>
-->
</sect2>
</sect1>
......
doc/src/sgml/plsql.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.17 2001/01/18 07:11:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.18 2001/01/20 20:59:29 petere Exp $
-->
<chapter id="plsql">
......@@ -170,9 +170,9 @@ END;
must also have a default value specified.
</para>
<para>
The default value is evaluated ever time the function is called. So
The default value is evaluated every time the function is called. So
assigning '<replaceable>now</replaceable>' to a variable of type
<replaceable>datetime</replaceable> causes the variable to have the
<type>timestamp</type> causes the variable to have the
time of the actual function call, not when the function was
precompiled into its bytecode.
</para>
......@@ -322,7 +322,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
All expressions used in PL/pgSQL statements are processed using
the backend's executor. Expressions that appear to contain
constants may in fact require run-time evaluation (e.g. 'now' for the
datetime type) so
<type>timestamp</type> type) so
it is impossible for the PL/pgSQL parser
to identify real constant values other than the NULL keyword. All
expressions are evaluated internally by executing a query
......@@ -343,7 +343,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
is a difference between what the two functions
<programlisting>
CREATE FUNCTION logfunc1 (text) RETURNS datetime AS '
CREATE FUNCTION logfunc1 (text) RETURNS timestamp AS '
DECLARE
logtxt ALIAS FOR $1;
BEGIN
......@@ -356,10 +356,10 @@ CREATE FUNCTION logfunc1 (text) RETURNS datetime AS '
and
<programlisting>
CREATE FUNCTION logfunc2 (text) RETURNS datetime AS '
CREATE FUNCTION logfunc2 (text) RETURNS timestamp AS '
DECLARE
logtxt ALIAS FOR $1;
curtime datetime;
curtime timestamp;
BEGIN
curtime := ''now'';
INSERT INTO logtable VALUES (logtxt, curtime);
......@@ -371,7 +371,7 @@ CREATE FUNCTION logfunc2 (text) RETURNS datetime AS '
do. In the case of logfunc1(), the <productname>Postgres</productname>
main parser
knows when preparing the plan for the INSERT, that the string 'now'
should be interpreted as datetime because the target field of logtable
should be interpreted as <type>timestamp</type> because the target field of logtable
is of that type. Thus, it will make a constant from it at this time
and this constant value is then used in all invocations of logfunc1()
during the lifetime of the backend. Needless to say that this isn't what the
......@@ -383,7 +383,7 @@ CREATE FUNCTION logfunc2 (text) RETURNS datetime AS '
what type 'now' should become and therefore it returns a data type of
text containing the string 'now'. During the assignment
to the local variable curtime, the PL/pgSQL interpreter casts this
string to the datetime type by calling the text_out() and datetime_in()
string to the timestamp type by calling the text_out() and timestamp_in()
functions for the conversion.
</para>
<para>
......@@ -855,7 +855,7 @@ EXIT [ <replaceable>label</replaceable> ] [ WHEN <replaceable>expression</replac
counterparts from the C language function discussion.
<programlisting>
CREATE FUNCTION add_one (int4) RETURNS int4 AS '
CREATE FUNCTION add_one (integer) RETURNS integer AS '
BEGIN
RETURN $1 + 1;
END;
......@@ -881,7 +881,7 @@ CREATE FUNCTION concat_text (text, text) RETURNS text AS '
The C functions.
<programlisting>
CREATE FUNCTION c_overpaid (EMP, int4) RETURNS bool AS '
CREATE FUNCTION c_overpaid (EMP, integer) RETURNS bool AS '
DECLARE
emprec ALIAS FOR $1;
sallim ALIAS FOR $2;
......@@ -909,9 +909,9 @@ CREATE FUNCTION c_overpaid (EMP, int4) RETURNS bool AS '
<programlisting>
CREATE TABLE emp (
empname text,
salary int4,
last_date datetime,
last_user name);
salary integer,
last_date timestamp,
last_user text);
CREATE FUNCTION emp_stamp () RETURNS OPAQUE AS '
BEGIN
......@@ -930,7 +930,7 @@ CREATE FUNCTION emp_stamp () RETURNS OPAQUE AS '
-- Remember who changed the payroll when
NEW.last_date := ''now'';
NEW.last_user := getpgusername();
NEW.last_user := current_user;
RETURN NEW;
END;
' LANGUAGE 'plpgsql';
......
doc/src/sgml/ref/comment.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/comment.sgml,v 1.5 2000/12/10 21:56:00 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/comment.sgml,v 1.6 2001/01/20 20:59:29 petere Exp $
Postgres documentation
-->
......@@ -131,8 +131,8 @@ COMMENT ON TABLE my_table IS 'Employee Information';
COMMENT ON TYPE my_type IS 'Complex Number support';
COMMENT ON VIEW my_view IS 'View of departmental costs';
COMMENT ON COLUMN my_table.my_field IS 'Employee ID number';
COMMENT ON AGGREGATE my_aggregate float8 IS 'Computes sample variance';
COMMENT ON FUNCTION my_function (datetime) IS 'Returns Roman Numeral';
COMMENT ON AGGREGATE my_aggregate (double precision) IS 'Computes sample variance';
COMMENT ON FUNCTION my_function (timestamp) IS 'Returns Roman Numeral';
COMMENT ON OPERATOR ^ (text, text) IS 'Performs intersection of two text';
COMMENT ON TRIGGER my_trigger ON my_table IS 'Used for R.I.';
</programlisting>
......
doc/src/sgml/ref/create_aggregate.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.12 2000/10/05 19:48:17 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.13 2001/01/20 20:59:29 petere Exp $
Postgres documentation
-->
......@@ -159,8 +159,8 @@ CREATE
<command>CREATE AGGREGATE</command>
allows a user or programmer to extend <productname>Postgres</productname>
functionality by defining new aggregate functions. Some aggregate functions
for base types such as <function>min(int4)</function>
and <function>avg(float8)</function> are already provided in the base
for base types such as <function>min(integer)</function>
and <function>avg(double precision)</function> are already provided in the base
distribution. If one defines new types or needs an aggregate function not
already provided, then <command>CREATE AGGREGATE</command>
can be used to provide the desired features.
......
doc/src/sgml/rules.sgml
View file @ 74bbe809
......@@ -1053,8 +1053,8 @@
CREATE TABLE shoelace_log (
sl_name char(10), -- shoelace changed
sl_avail integer, -- new available value
log_who name, -- who did it
log_when datetime -- when
log_who text, -- who did it
log_when timestamp -- when
);
CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data
......@@ -1062,21 +1062,10 @@
DO INSERT INTO shoelace_log VALUES (
NEW.sl_name,
NEW.sl_avail,
getpgusername(),
'now'::text
current_user,
current_timestamp
);
</ProgramListing>
One interesting detail is the casting of 'now' in the rules
INSERT action to type text. Without that, the parser would see
at CREATE RULE time, that the target type in <Filename>shoelace_log</Filename>
is a datetime and tries to make a constant from it - with success.
So a constant datetime value would be stored in the rule action
and all log entries would have the time of the CREATE RULE statement.
Not exactly what we want. The casting causes the parser to
construct a datetime('now'::text) expression and this will be
evaluated when the rule is executed. (Another way to do this is to
use the function now() instead of a literal constant.)
</Para>
<Para>
......@@ -1120,7 +1109,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*;
</ProgramListing>
......@@ -1140,7 +1129,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
<FirstTerm>shoelace_data shoelace_data</FirstTerm>;
</ProgramListing>
......@@ -1151,7 +1140,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
<FirstTerm>WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)</FirstTerm>;
......@@ -1169,7 +1158,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)
......@@ -1183,7 +1172,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
<FirstTerm>shoelace_data.sl_name</FirstTerm>, <FirstTerm>6</FirstTerm>,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(<FirstTerm>6</FirstTerm>, *OLD*.sl_avail)
......@@ -1195,7 +1184,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(6, <FirstTerm>shoelace_data.sl_avail</FirstTerm>)
......@@ -1209,7 +1198,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
getpgusername(), datetime('now'::text))
current_user, current_timestamp
FROM shoelace_data
WHERE 6 != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
......@@ -1235,7 +1224,7 @@
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, <FirstTerm>shoelace_data.sl_avail</FirstTerm>,
getpgusername(), 'now')
current_user, current_timestamp)
FROM shoelace_data
WHERE <FirstTerm>shoelace_data.sl_avail</FirstTerm> != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
......@@ -1258,7 +1247,7 @@
<ProgramListing>
INSERT INTO shoelace_log SELECT
shoelace_data.sl_name, 0,
getpgusername(), 'now'
current_user, current_timestamp
FROM shoelace_data
WHERE 0 != shoelace_data.sl_avail
AND <FirstTerm>shoelace_data.sl_color = 'black'</FirstTerm>;
......@@ -1512,8 +1501,8 @@
INSERT INTO shoelace_log SELECT
s.sl_name,
int4pl(s.sl_avail, shoelace_arrive.arr_quant),
getpgusername(),
datetime('now'::text)
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
......@@ -1537,8 +1526,8 @@
INSERT INTO shoelace_log SELECT
s.sl_name,
s.sl_avail + shoelace_arrive.arr_quant,
getpgusername(),
'now'
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.arr_name
......
doc/src/sgml/typeconv.sgml
View file @ 74bbe809
......@@ -307,7 +307,8 @@ then fail.
<para>
There is only one exponentiation
operator defined in the catalog, and it takes <type>float8</type> arguments.
operator defined in the catalog, and it takes arguments of type
<type>double precision</type>.
The scanner assigns an initial type of <type>int4</type> to both arguments
of this query expression:
<programlisting>
......@@ -322,7 +323,7 @@ So the parser does a type conversion on both operands and the query
is equivalent to
<programlisting>
tgl=> select float8(2) ^ float8(3) AS "Exp";
tgl=> select CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
Exp
-----
8
......@@ -754,8 +755,8 @@ Here, the unknown-type literal 'b' will be resolved as type text.
<para>
<programlisting>
tgl=> SELECT 1.2 AS "Float8" UNION SELECT 1;
Float8
tgl=> SELECT 1.2 AS "Double" UNION SELECT 1;
Double
--------
1
1.2
......@@ -773,7 +774,7 @@ the first/top clause in the union:
<programlisting>
tgl=> SELECT 1 AS "All integers"
tgl-> UNION SELECT '2.2'::float4;
tgl-> UNION SELECT CAST('2.2' AS REAL);
All integers
--------------
1
......@@ -782,8 +783,9 @@ tgl-> UNION SELECT '2.2'::float4;
</programlisting>
</para>
<para>
Since float4 is not a preferred type, the parser sees no reason to select it
over int4, and instead falls back on the use-the-first-alternative rule.
Since <type>REAL</type> is not a preferred type, the parser sees no reason
to select it over <type>INTEGER</type> (which is what the 1 is), and instead
falls back on the use-the-first-alternative rule.
This example demonstrates that the preferred-type mechanism doesn't encode
as much information as we'd like. Future versions of
<productname>Postgres</productname> may support a more general notion of
......
doc/src/sgml/xfunc.sgml
View file @ 74bbe809
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.28 2001/01/13 23:58:55 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.29 2001/01/20 20:59:29 petere Exp $
-->
<chapter id="xfunc">
......@@ -186,7 +186,7 @@ CREATE FUNCTION double_salary(EMP)
SELECT name, double_salary(EMP) AS dream
FROM EMP
WHERE EMP.cubicle ~= '(2,1)'::point;
WHERE EMP.cubicle ~= point '(2,1)';
+-----+-------+
......@@ -231,10 +231,10 @@ SELECT name(EMP) AS youngster
<programlisting>
CREATE FUNCTION new_emp()
RETURNS EMP
AS 'SELECT \'None\'::text AS name,
AS 'SELECT text ''None'' AS name,
1000 AS salary,
25 AS age,
\'(2,2)\'::point AS cubicle'
point ''(2,2)'' AS cubicle'
LANGUAGE 'sql';
</programlisting>
</para>
......@@ -255,7 +255,7 @@ CREATE FUNCTION new_emp()
</listitem>
<listitem>
<para>
You must typecast the expressions (using ::) to match the
You must typecast the expressions to match the
composite type's definition, or you will get errors like this:
<programlisting>
<computeroutput>
......@@ -1186,7 +1186,7 @@ LANGUAGE 'c';
<listitem>
<para>
Compiling and loading your object code so that
Compiling and linking your object code so that
it can be dynamically loaded into
<productname>Postgres</productname>
always requires special flags.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment