[DOCS] "FETCH returns data as if it were a SELECT result"

[Roman Neuhauser]

"The variant of FETCH described here returns the data as if it were a
SELECT result rather than placing it in host variables."

http://www.postgresql.org/docs/current/static/sql-fetch.html

That doesn't seem to be the case. Try the following script:

CREATE TABLE t1 (t1i INT, t1c CHAR(1));
CREATE TABLE t2 (t2i INT, t2c CHAR(1));

INSERT INTO t1 VALUES (1, 'a');
INSERT INTO t1 VALUES (2, 'b');
INSERT INTO t1 VALUES (3, 'c');

BEGIN;
INSERT INTO t2 (SELECT * FROM t1);
SELECT * FROM t2;
ROLLBACK;

BEGIN;
DECLARE c1 CURSOR FOR SELECT * FROM t1;
INSERT INTO t2 (FETCH ALL FROM c1);
ROLLBACK;

The output I get:

CREATE TABLE
CREATE TABLE
INSERT 19110 1
INSERT 19111 1
INSERT 19112 1
BEGIN
INSERT 0 3
 t2i | t2c 
-+-
   1 | a
   2 | b
   3 | c
(3 rows)

ROLLBACK
BEGIN
DECLARE CURSOR
psql:tmp/fetch-is-unlike-select.sql:15: ERROR:  syntax error at or near "ALL" 
at character 23
psql:tmp/fetch-is-unlike-select.sql:15: LINE 1: INSERT INTO t2 (FETCH ALL FROM 
c1);
psql:tmp/fetch-is-unlike-select.sql:15:   ^
ROLLBACK

This is on PostgreSQL 8.0.3 on i386-portbld-freebsd4.11, compiled by GCC 2.95.4

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [DOCS] "FETCH returns data as if it were a SELECT result"

[Tom Lane]

Roman Neuhauser <[EMAIL PROTECTED]> writes:
> "The variant of FETCH described here returns the data as if it were a
> SELECT result rather than placing it in host variables."

> That doesn't seem to be the case.

It means it returns data *to the client* in the same way a SELECT does.

regards, tom lane

---(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

Re: [DOCS] "FETCH returns data as if it were a SELECT result"

[Roman Neuhauser]

# [EMAIL PROTECTED] / 2005-08-02 13:09:58 -0400:
> Roman Neuhauser <[EMAIL PROTECTED]> writes:
> > "The variant of FETCH described here returns the data as if it were a
> > SELECT result rather than placing it in host variables."
> 
> > That doesn't seem to be the case.
> 
> It means it returns data *to the client* in the same way a SELECT does.

Ok, and what does *that* mean? If you spend a few minutes on an
explanation, I'll submit a patch to the documentation.

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[DOCS] unsubscribe

[Norm Costa]

unsubscribe
 





Sent via the WebMail system at expertss.com


 
   

---(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