This documentation bug has been fixed. We currently have:
=> SELECT * FROM a;
x
---
1 -- no rows in a (0) + 1
(1 row)
=> INSERT INTO a VALUES (execq('SELECT * FROM a', 0) + 1);
INFO: EXECQ: 1
INSERT 0 1
Is the "INSERT 0 1" right? I see an oid in your example, but that might
be because we no longer user oids by default.
---------------------------------------------------------------------------
Yoshihisa Nakano wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2096
> Logged by: Yoshihisa Nakano
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.0
> Operating system: RedHat Enterprise Linux ES 3.0
> Description: bug in a SPI sample document
> Details:
>
> There is a difference between the result of the SPI
> example in the doc and the actual result of that.
>
>
> Doc 40.5 Examples
> => SELECT * FROM a;
> x
> ---
> 1 -- no rows in a (0) + 1
> (1 row)
>
> => INSERT INTO a VALUES (execq('SELECT * FROM a', 0) + 1);
> INFO: EXECQ: 0
> INSERT 167713 1
>
>
> I tried this example, but INFO showed 1, not 0. I
> think the value of INFO in doc is wrong, because the
> value of row is 1 at this time.
>
> This bug seems to exist also in 7.3.x, 7.4.x and 8.0.x.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
