pgsql: Change FETCH/MOVE to use int8.
Log Message:
-----------
Change FETCH/MOVE to use int8.
Dhanaraj M
Modified Files:
--------------
pgsql/src/backend/commands:
portalcmds.c (r1.51 -> r1.52)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/portalcmds.c.diff?r1=1.51&r2=1.52)
pgsql/src/backend/executor:
spi.c (r1.159 -> r1.160)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c.diff?r1=1.159&r2=1.160)
pgsql/src/backend/parser:
gram.y (r2.559 -> r2.560)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y.diff?r1=2.559&r2=2.560)
scan.l (r1.135 -> r1.136)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/scan.l.diff?r1=1.135&r2=1.136)
pgsql/src/backend/tcop:
postgres.c (r1.503 -> r1.504)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c.diff?r1=1.503&r2=1.504)
pquery.c (r1.107 -> r1.108)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/pquery.c.diff?r1=1.107&r2=1.108)
pgsql/src/include/executor:
spi.h (r1.55 -> r1.56)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/spi.h.diff?r1=1.55&r2=1.56)
pgsql/src/include/nodes:
parsenodes.h (r1.326 -> r1.327)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/parsenodes.h.diff?r1=1.326&r2=1.327)
pgsql/src/include/tcop:
pquery.h (r1.37 -> r1.38)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/tcop/pquery.h.diff?r1=1.37&r2=1.38)
pgsql/src/include/utils:
portal.h (r1.67 -> r1.68)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/portal.h.diff?r1=1.67&r2=1.68)
momjian@postgresql.org (Bruce Momjian) writes:
Log Message:
-----------
Change FETCH/MOVE to use int8.
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
regards, tom lane
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
Log Message:
-----------
Change FETCH/MOVE to use int8.This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for > 2gig tables.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/bjm/difftext/x-diffDownload+9-2
Bruce Momjian <bruce@momjian.us> writes:
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for > 2gig tables.
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for >2G tables). It is not worth the
extra computational cycles that it imposes on every machine whether they
use the feature or not, and it is certainly not worth the developer time
we're expending to fix this poorly written patch. Please revert it.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.Fixed with attached patch. The use case for this was not FETCH, but
MOVE for > 2gig tables.There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for >2G tables). It is not worth the
extra computational cycles that it imposes on every machine whether they
use the feature or not, and it is certainly not worth the developer time
we're expending to fix this poorly written patch. Please revert it.
Already done because of bad coding. You want the TODO item removed too?
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for >2G tables).
Already done because of bad coding. You want the TODO item removed too?
As I said, I see no use case for it. Maybe if Moore's Law holds up for
another five or ten years, it'll look like a useful feature then ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for >2G tables).Already done because of bad coding. You want the TODO item removed too?
As I said, I see no use case for it. Maybe if Moore's Law holds up for
another five or ten years, it'll look like a useful feature then ...
Removed.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +