Обсуждение: Rule system goes weird with SELECT queries
I must admit I'm trying to (ab)use the rule system into being a stored-procedure system, so maybe I'm just getting what I deserve. However, the results I'm getting are just plain weird. If I define two rules for the same action, each with a single select command, I wind up with two selects as expected, but they are both cross-product selects on the two tables. This is unexpected. If I change the grammar rules so that I can have a compound action with two selects, I get two selects, each effectively the four-times cross-product of the selects. Talk about exponential growth!! Now I can see why compound SELECTs were disallowed. And I can guess why my two separate rules behaved this way, sort of. But if I'm right, the rules are being processed by the planner once on creation and again when being invoked, and something is not quite right about it. But: does anyone else see a need for a stored-procedure facility, different from function definition? I'm probably going to do it anyway, but if there's support for the idea, I will try to make it conform to the standards of the community. In return for a little guidance on that subject. Here are the details (all tables initially empty): Form 1: two separate rules gives two cross-products. create rule rule4a as on insert to dummy do instead select * from d2; create rule rule4b as on insert to dummy do instead select * from d3; explain insert into dummy values(1); psql:rule4.sql:14: NOTICE: QUERY PLAN: Nested Loop (cost=0.00..30020.00 rows=1000000 width=8) -> Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4) -> SeqScan on d2 (cost=0.00..20.00 rows=1000 width=4) psql:rule4.sql:14: NOTICE: QUERY PLAN: Nested Loop (cost=0.00..30020.00 rows=1000000 width=8) -> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) -> SeqScan on d3 (cost=0.00..20.00 rows=1000 width=4) EXPLAIN Form 2: single rule with two SELECT commands gives something quite weird apparently a quadruple cross-product, performed twice: create rule rule3 as on insert to dummy do instead (select * from d2; select * from d3;); explain insert into dummy values(1); psql:rule3.sql:13: NOTICE: QUERY PLAN: Nested Loop (cost=0.00..30030030020.00 rows=1000000000000 width=16) -> Nested Loop (cost=0.00..30030020.00 rows=1000000000width=12) -> Nested Loop (cost=0.00..30020.00 rows=1000000 width=8) -> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) -> Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4) -> SeqScan on d3 (cost=0.00..20.00 rows=1000 width=4) -> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) psql:rule3.sql:13: NOTICE: QUERY PLAN: Nested Loop (cost=0.00..30030030020.00 rows=1000000000000 width=16) -> Nested Loop (cost=0.00..30030020.00 rows=1000000000width=12) -> Nested Loop (cost=0.00..30020.00 rows=1000000 width=8) -> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) -> Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4) -> SeqScan on d3 (cost=0.00..20.00 rows=1000 width=4) -> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) EXPLAIN -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead
"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> If I define two rules for the same action, each with
> a single select command, I wind up with two selects as
> expected, but they are both cross-product selects on the
> two tables. This is unexpected.
Rangetable leakage, sounds like --- the two queries are sharing the same
list of rangetable entries, and that's what the planner joins over. Not
sure if it's *good* that they share the same rtable list, or if that's a
bug. In any event, it's old news because current sources don't use the
rtable list to control joining; now there is a separate join tree, which
is definitely not shared. I get
regression=# create rule rule4a as on insert to dummy do instead select * from
d2;
CREATE
regression=# create rule rule4b as on insert to dummy do instead select * from
d3;
CREATE
regression=# explain insert into dummy values(1);
NOTICE: QUERY PLAN:
Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4)
NOTICE: QUERY PLAN:
Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4)
EXPLAIN
which looks fine. Can't check your other example, since the grammar
file hasn't been changed to allow it...
I'm not sure whether to recommend that you work from current CVS sources
or not. A couple weeks ago that's what I would have said, but Vadim is
halfway through integrating WAL changes and I'm not sure how stable the
tip really is. You could try the tip, and if it blows up fall back to
a dated retrieval from about 7-Oct. Or you could investigate the way
that the 7.0.* rewriter handles the rtable list for multiple queries,
but that's probably not a real profitable use of your time.
regards, tom lane
Thanks for the reply. I'll look into setting up CVS -- I've just been using the distributed 7.0.2 actually. Moreover, the situation is even a bit more confused for me. When I actually *execute* the 'insert into dummy', I get the output of only one select: the second one listed. Is there something about executing a list I don't know about, or is this also old news?? ++ kevin Tom Lane wrote: > > "Kevin O'Gorman" <kogorman@pacbell.net> writes: > > If I define two rules for the same action, each with > > a single select command, I wind up with two selects as > > expected, but they are both cross-product selects on the > > two tables. This is unexpected. > > Rangetable leakage, sounds like --- the two queries are sharing the same > list of rangetable entries, and that's what the planner joins over. Not > sure if it's *good* that they share the same rtable list, or if that's a > bug. In any event, it's old news because current sources don't use the > rtable list to control joining; now there is a separate join tree, which > is definitely not shared. I get > > regression=# create rule rule4a as on insert to dummy do instead select * from > d2; > CREATE > regression=# create rule rule4b as on insert to dummy do instead select * from > d3; > CREATE > regression=# explain insert into dummy values(1); > NOTICE: QUERY PLAN: > > Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4) > > NOTICE: QUERY PLAN: > > Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4) > > EXPLAIN > > which looks fine. Can't check your other example, since the grammar > file hasn't been changed to allow it... > > I'm not sure whether to recommend that you work from current CVS sources > or not. A couple weeks ago that's what I would have said, but Vadim is > halfway through integrating WAL changes and I'm not sure how stable the > tip really is. You could try the tip, and if it blows up fall back to > a dated retrieval from about 7-Oct. Or you could investigate the way > that the 7.0.* rewriter handles the rtable list for multiple queries, > but that's probably not a real profitable use of your time. > > regards, tom lane -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead
"Kevin O'Gorman" <kogorman@pacbell.net> writes: > When I actually *execute* the 'insert into dummy', I get the output of > only one select: the second one listed. Is there something about > executing a list I don't know about, or is this also old news?? If you're using psql then that doesn't surprise me, because psql submits queries via PQexec, and PQexec is not capable of dealing with multiple result sets per submitted query string --- its API provides no way to handle that, so it just bit-buckets all but the last command result. This would work OK in an app that uses PQsendQuery followed by a PQgetResult loop, however. See http://www.postgresql.org/devel-corner/docs/postgres/libpq-async.htm I've been kind of wanting to update psql to use these lower-level routines, but that item has been languishing in the to-do queue for a couple years now... regards, tom lane
Tom Lane wrote: > I'm not sure whether to recommend that you work from current CVS sources > or not. A couple weeks ago that's what I would have said, but Vadim is > halfway through integrating WAL changes and I'm not sure how stable the > tip really is. You could try the tip, and if it blows up fall back to > a dated retrieval from about 7-Oct. Or you could investigate the way > that the 7.0.* rewriter handles the rtable list for multiple queries, > but that's probably not a real profitable use of your time. > > regards, tom lane Well, I tried the tip of the tree today, and initdb fails to complete, so I tried going back to '7 Oct 2000 10:00:00 PST' and it's better, but regression tests fail on the rule system. It makes the server die. Since rules are what I want, this won't do. I'm not familiar enough with CVS or your changelog system well enough to know a good way to find a time-point that might be stable enough for me. How would I find out where I need to be?? ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead
"Kevin O'Gorman" <kogorman@pacbell.net> writes: > so I tried going back to '7 Oct 2000 10:00:00 PST' and it's better, > but regression tests fail on the rule system. It makes the server > die. Since rules are what I want, this won't do. Details? AFAIK, the system was operational on 7-Oct; I did not pick that date out of the air. There was a broken version of the expected/rules.out file in place right around then --- see http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/test/regress/expected/rules.out But that'd just have caused a bogus comparison failure, not a server crash. (What was *in the expected file* was a report of a server crash :-(, so if you didn't look carefully at the diff you might've gotten confused...) If you want a more exact timestamp, try 7-Oct-2000 00:00 PDT which predates the BEOS patch breakage, or 8-Oct-2000 00:00 PDT which follows cleanup. If either of those fail on your system it'd be useful to know about. regards, tom lane
"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> It's odd. I had already tried "8 Oct 2000 10:00:00 PDT" on one system
> (RedHat Linux 6.1), and it had worked. Today I'm building on a
> Caldera 2.3 system, and both the 00:00 and 10:00 builds fail.
Hm. Portability bug maybe? But I can't tell with no info.
> I've attached the output of the make.
Uh, it looked more like an amazon.com search from here...
regards, tom lane
Tom Lane wrote: > > "Kevin O'Gorman" <kogorman@pacbell.net> writes: > > so I tried going back to '7 Oct 2000 10:00:00 PST' and it's better, > > but regression tests fail on the rule system. It makes the server > > die. Since rules are what I want, this won't do. > > Details? AFAIK, the system was operational on 7-Oct; I did not pick > that date out of the air. There was a broken version of the > expected/rules.out file in place right around then --- see > http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/test/regress/expected/rules.out > But that'd just have caused a bogus comparison failure, not a server > crash. (What was *in the expected file* was a report of a server > crash :-(, so if you didn't look carefully at the diff you might've > gotten confused...) > > If you want a more exact timestamp, try 7-Oct-2000 00:00 PDT which > predates the BEOS patch breakage, or 8-Oct-2000 00:00 PDT which follows > cleanup. If either of those fail on your system it'd be useful to know > about. > > regards, tom lane It's odd. I had already tried "8 Oct 2000 10:00:00 PDT" on one system (RedHat Linux 6.1), and it had worked. Today I'm building on a Caldera 2.3 system, and both the 00:00 and 10:00 builds fail. I've attached the output of the make. Could I have a bad copy of this source file? How could I tell (not knowing much about CVS, I'm disinclined to perform random experiments). ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead
Tom Lane wrote: > > "Kevin O'Gorman" <kogorman@pacbell.net> writes: > > It's odd. I had already tried "8 Oct 2000 10:00:00 PDT" on one system > > (RedHat Linux 6.1), and it had worked. Today I'm building on a > > Caldera 2.3 system, and both the 00:00 and 10:00 builds fail. > > Hm. Portability bug maybe? But I can't tell with no info. > > > I've attached the output of the make. > > Uh, it looked more like an amazon.com search from here... > > regards, tom lane Uh, so it does. How embarassing. I've been having MORE trouble with Netscape... Anyway, here it is again. In the meantime, I did a diff with the version on a system that made okay, and there are no source differences in the pg_backup_custom.c file. If we get browser junk again, here is the tail of the file via cut-and-paste; there are about 100 lines of error output total: pg_backup_custom.c: In function `_DoDeflate': pg_backup_custom.c:846: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:846: parse error before `zp' pg_backup_custom.c:849: `ctx' undeclared (first use in this function) pg_backup_custom.c:852: `AH' undeclared (first use in this function) pg_backup_custom.c:854: `zp' undeclared (first use in this function) pg_backup_custom.c:854: `flush' undeclared (first use in this function) pg_backup_custom.c: In function `_EndDataCompressor': pg_backup_custom.c:912: `ctx' undeclared (first use in this function) pg_backup_custom.c:912: parse error before `)' pg_backup_custom.c:913: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:918: `zp' undeclared (first use in this function) make[3]: *** [pg_backup_custom.o] Error 1 make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/pgsql/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/pgsql/src' make: *** [all] Error 2 [kevin@trixie pgsql]$ exit Script done, file is typescript ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North WhiteheadScript started on Sun Oct 22 21:33:56 2000 /home/kevin/.bashrc /home/kevin/.bashrc-private [kevin@trixie pgsql]$ make make -C doc all make[1]: Entering directory `/usr/local/src/pgsql/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/pgsql/doc' make -C src all make[1]: Entering directory `/usr/local/src/pgsql/src' make -C backend all make[2]: Entering directory `/usr/local/src/pgsql/src/backend' make -C access all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/access' make -C common SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/common' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/common' make -C gist SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/gist' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/gist' make -C hash SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/hash' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/hash' make -C heap SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/heap' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/heap' make -C index SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/index' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/index' make -C nbtree SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/nbtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/nbtree' make -C rtree SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/rtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/rtree' make -C transam SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/transam' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/transam' make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/access' make -C bootstrap all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/bootstrap' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/bootstrap' make -C catalog all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/catalog' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/catalog' make -C parser all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/parser' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/parser' make -C commands all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/commands' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/commands' make -C executor all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/executor' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/executor' make -C lib all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/lib' make -C libpq all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/libpq' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/libpq' make -C main all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/main' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/main' make -C nodes all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/nodes' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/nodes' make -C optimizer all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer' make -C geqo SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer/geqo' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer/geqo' make -C path SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer/path' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer/path' make -C plan SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer/plan' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer/plan' make -C prep SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer/prep' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer/prep' make -C util SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/optimizer/util' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer/util' make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/optimizer' make -C port all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/port' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/port' make -C postmaster all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/postmaster' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/postmaster' make -C regex all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/regex' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/regex' make -C rewrite all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/rewrite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/rewrite' make -C storage all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/storage' make -C buffer SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/buffer' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/buffer' make -C file SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/file' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/file' make -C ipc SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/ipc' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/ipc' make -C large_object SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/large_object' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/large_object' make -C lmgr SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/lmgr' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/lmgr' make -C page SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/page' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/page' make -C smgr SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/storage/smgr' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/storage/smgr' make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/storage' make -C tcop all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/tcop' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/tcop' make -C utils all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/utils' make -C adt SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/adt' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/adt' make -C cache SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/cache' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/cache' make -C error SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/error' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/error' make -C fmgr SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/fmgr' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/fmgr' make -C hash SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/hash' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/hash' make -C init SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/init' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/init' make -C misc SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/misc' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/misc' make -C mmgr SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/mmgr' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/mmgr' make -C sort SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/sort' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/sort' make -C time SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/time' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/time' make -C mb SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/utils/mb' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/utils/mb' make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/utils' make[2]: Leaving directory `/usr/local/src/pgsql/src/backend' make -C include all make[2]: Entering directory `/usr/local/src/pgsql/src/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/pgsql/src/include' make -C interfaces all make[2]: Entering directory `/usr/local/src/pgsql/src/interfaces' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/ecpg' make -C include all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/ecpg/include' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/ecpg/include' make -C lib all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/ecpg/lib' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/ecpg/lib' make -C preproc all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/ecpg/preproc' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/ecpg/preproc' make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/ecpg' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpgeasy' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpgeasy' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/odbc' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/odbc' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq++' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq++' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpgtcl' make -C ../../../src/interfaces/libpq all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq' make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpgtcl' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/perl5' make -C ../../../src/interfaces/libpq all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq' make -f Makefile all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/perl5' make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/perl5' make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/perl5' make[3]: Entering directory `/usr/local/src/pgsql/src/interfaces/python' make -C ../../../src/interfaces/libpq all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq' make -f Makefile make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/python' make[4]: Nothing to be done for `default'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/python' make[3]: Leaving directory `/usr/local/src/pgsql/src/interfaces/python' make[2]: Leaving directory `/usr/local/src/pgsql/src/interfaces' make -C bin all make[2]: Entering directory `/usr/local/src/pgsql/src/bin' make[3]: Entering directory `/usr/local/src/pgsql/src/bin/initdb' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/initdb' make[3]: Entering directory `/usr/local/src/pgsql/src/bin/initlocation' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/initlocation' make[3]: Entering directory `/usr/local/src/pgsql/src/bin/ipcclean' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/ipcclean' make[3]: Entering directory `/usr/local/src/pgsql/src/bin/pg_ctl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/pg_ctl' make[3]: Entering directory `/usr/local/src/pgsql/src/bin/pg_dump' make -C ../../../src/interfaces/libpq all make[4]: Entering directory `/usr/local/src/pgsql/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/usr/local/src/pgsql/src/interfaces/libpq' gcc -c -I../../../src/interfaces/libpq -I../../../src/include -I../../../src/interfaces/libpq -O2 -g -Wall -Wmissing-prototypes-Wmissing-declarations pg_backup_custom.c -o pg_backup_custom.o pg_backup_custom.c:73: parse error before `z_streamp' pg_backup_custom.c:73: warning: no semicolon at end of struct or union pg_backup_custom.c:80: parse error before `}' pg_backup_custom.c:80: warning: type defaults to `int' in declaration of `lclContext' pg_backup_custom.c:80: warning: data definition has no type or storage class pg_backup_custom.c:95: parse error before `lclContext' pg_backup_custom.c:96: parse error before `lclContext' pg_backup_custom.c: In function `InitArchiveFmt_Custom': pg_backup_custom.c:114: `ctx' undeclared (first use in this function) pg_backup_custom.c:114: (Each undeclared identifier is reported only once pg_backup_custom.c:114: for each function it appears in.) pg_backup_custom.c:114: warning: statement with no effect pg_backup_custom.c:139: parse error before `)' pg_backup_custom.c:144: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:144: parse error before `malloc' pg_backup_custom.c: In function `_StartData': pg_backup_custom.c:277: `ctx' undeclared (first use in this function) pg_backup_custom.c:277: parse error before `)' pg_backup_custom.c: In function `_WriteData': pg_backup_custom.c:301: `ctx' undeclared (first use in this function) pg_backup_custom.c:301: parse error before `)' pg_backup_custom.c:302: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:304: `zp' undeclared (first use in this function) pg_backup_custom.c: In function `_EndData': pg_backup_custom.c:323: `ctx' undeclared (first use in this function) pg_backup_custom.c:323: parse error before `)' pg_backup_custom.c: In function `_StartBlobs': pg_backup_custom.c:343: `ctx' undeclared (first use in this function) pg_backup_custom.c:343: parse error before `)' pg_backup_custom.c: In function `_PrintTocData': pg_backup_custom.c:397: `ctx' undeclared (first use in this function) pg_backup_custom.c:397: parse error before `)' pg_backup_custom.c: In function `_PrintData': pg_backup_custom.c:489: `ctx' undeclared (first use in this function) pg_backup_custom.c:489: parse error before `)' pg_backup_custom.c:490: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:504: `zp' undeclared (first use in this function) pg_backup_custom.c: In function `_skipData': pg_backup_custom.c:623: `ctx' undeclared (first use in this function) pg_backup_custom.c:623: parse error before `)' pg_backup_custom.c: In function `_WriteByte': pg_backup_custom.c:658: `ctx' undeclared (first use in this function) pg_backup_custom.c:658: parse error before `)' pg_backup_custom.c: In function `_ReadByte': pg_backup_custom.c:679: `ctx' undeclared (first use in this function) pg_backup_custom.c:679: parse error before `)' pg_backup_custom.c: In function `_WriteBuf': pg_backup_custom.c:700: `ctx' undeclared (first use in this function) pg_backup_custom.c:700: parse error before `)' pg_backup_custom.c: In function `_ReadBuf': pg_backup_custom.c:718: `ctx' undeclared (first use in this function) pg_backup_custom.c:718: parse error before `)' pg_backup_custom.c: In function `_CloseArchive': pg_backup_custom.c:742: `ctx' undeclared (first use in this function) pg_backup_custom.c:742: parse error before `)' pg_backup_custom.c: At top level: pg_backup_custom.c:774: parse error before `lclContext' pg_backup_custom.c:775: warning: `_getFilePos' was used with no prototype before its definition pg_backup_custom.c: In function `_getFilePos': pg_backup_custom.c:777: `ctx' undeclared (first use in this function) pg_backup_custom.c:778: `AH' undeclared (first use in this function) pg_backup_custom.c: In function `_StartDataCompressor': pg_backup_custom.c:809: `ctx' undeclared (first use in this function) pg_backup_custom.c:809: parse error before `)' pg_backup_custom.c:810: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:819: `zp' undeclared (first use in this function) pg_backup_custom.c: At top level: pg_backup_custom.c:844: parse error before `lclContext' pg_backup_custom.c:845: warning: `_DoDeflate' was used with no prototype before its definition pg_backup_custom.c: In function `_DoDeflate': pg_backup_custom.c:846: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:846: parse error before `zp' pg_backup_custom.c:849: `ctx' undeclared (first use in this function) pg_backup_custom.c:852: `AH' undeclared (first use in this function) pg_backup_custom.c:854: `zp' undeclared (first use in this function) pg_backup_custom.c:854: `flush' undeclared (first use in this function) pg_backup_custom.c: In function `_EndDataCompressor': pg_backup_custom.c:912: `ctx' undeclared (first use in this function) pg_backup_custom.c:912: parse error before `)' pg_backup_custom.c:913: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:918: `zp' undeclared (first use in this function) make[3]: *** [pg_backup_custom.o] Error 1 make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/pgsql/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/pgsql/src' make: *** [all] Error 2 [kevin@trixie pgsql]$ exit Script done on Sun Oct 22 21:37:16 2000
"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> pg_backup_custom.c: In function `_DoDeflate':
> pg_backup_custom.c:846: `z_streamp' undeclared (first use in this function)
> pg_backup_custom.c:846: parse error before `zp'
> pg_backup_custom.c:849: `ctx' undeclared (first use in this function)
> pg_backup_custom.c:852: `AH' undeclared (first use in this function)
> pg_backup_custom.c:854: `zp' undeclared (first use in this function)
> pg_backup_custom.c:854: `flush' undeclared (first use in this function)
> pg_backup_custom.c: In function `_EndDataCompressor':
> pg_backup_custom.c:912: `ctx' undeclared (first use in this function)
> pg_backup_custom.c:912: parse error before `)'
> pg_backup_custom.c:913: `z_streamp' undeclared (first use in this function)
> pg_backup_custom.c:918: `zp' undeclared (first use in this function)
Hmm. Looks like Philip neglected to see to it that pg_dump will compile
when libz is not present --- the "#include <zlib.h>" is properly ifdef'd
out, but the code isn't. Over to you, Philip ...
regards, tom lane