Re: [HACKERS] findoidjoins
Joe Conway [EMAIL PROTECTED] writes: I'm not sure I interpreted the intent of findoidjoins just right, but here it is updated for schemas, new reg* types, using SPI instead of libpgeasy, and returning the results as a table function. Any corrections/comments? For what we want it for (viz, regenerating the oidjoins test every so often), this is really a step backwards. It requires more work to run than the original program, and it modifies the database under test, which is undesirable because it's commonly run against template1. I was thinking of keeping it as a client program, but recasting it to use libpq since libpgeasy isn't in the standard distribution anymore. I've looked through my notes and I can't find why I thought findoidjoins was broken for 7.3. Did you come across anything obviously wrong with its queries? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] findoidjoins
Tom Lane wrote: For what we want it for (viz, regenerating the oidjoins test every so often), this is really a step backwards. It requires more work to run than the original program, and it modifies the database under test, which is undesirable because it's commonly run against template1. I was thinking of keeping it as a client program, but recasting it to use libpq since libpgeasy isn't in the standard distribution anymore. OK. I'll take another shot using that approach. A couple questions: Is it useful to have the reference count and unreferenced counts like currently written, or should I just faithfully reproduce the original behavior (except schema aware queries) using libpq in place of libpgeasy? Is the oidjoins.sql test just the output of the make_oidjoins_check script? It is probably easier to produce that output while looping through the first time versus running a script -- should I do that? I've looked through my notes and I can't find why I thought findoidjoins was broken for 7.3. Did you come across anything obviously wrong with its queries? As written the queries did not know anything about schemas or the newer reg* data types, e.g. this: SELECT typname, relname, a.attname FROM pg_class c, pg_attribute a, pg_type t WHERE a.attnum 0 AND relkind = 'r' AND (typname = 'oid' OR typname = 'regproc' OR typname = 'regclass' OR typname = 'regtype') AND a.attrelid = c.oid AND a.atttypid = t.oid ORDER BY 2, a.attnum ; became this: SELECT c.relname, (SELECT nspname FROM pg_catalog.pg_namespace n WHERE n.oid = c.relnamespace) AS nspname, a.attname, t.typname FROM pg_catalog.pg_class c, pg_catalog.pg_attribute a, pg_catalog.pg_type t WHERE a.attnum 0 AND c.relkind = 'r' AND t.typnamespace IN (SELECT n.oid FROM pg_catalog.pg_namespace n WHERE nspname LIKE 'pg\\_%') AND (t.typname = 'oid' OR t.typname LIKE 'reg%') AND a.attrelid = c.oid AND a.atttypid = t.oid ORDER BY nspname, c.relname, a.attnum Does the latter produce the desired result? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] findoidjoins
Joe Conway [EMAIL PROTECTED] writes: Is it useful to have the reference count and unreferenced counts like currently written, or should I just faithfully reproduce the original behavior (except schema aware queries) using libpq in place of libpgeasy? I'd be inclined to reproduce the original behavior. findoidjoins is pretty slow already, and I don't much want to slow it down more in order to provide info that's useless for the primary purpose. Is the oidjoins.sql test just the output of the make_oidjoins_check script? Yes. It is probably easier to produce that output while looping through the first time versus running a script -- should I do that? The separation between findoidjoins and make_oidjoins_check is deliberate --- this allows for easy hand-editing of the join list to remove unwanted joins before preparing the regression test script (cf the notes in the README about bogus joins). Even though this is an extra manual step, I think it's a better answer than trying to make findoidjoins smart enough to suppress the bogus joins itself. Part of the reason for running findoidjoins is to detect any unexpected linkages, so it should not be too eager to hide things. Also, because the output of findoidjoins *should* be manually reviewed, it's better to put it out in an easy-to-read one-line-per-join format than to put out the finished regression script directly. I've looked through my notes and I can't find why I thought findoidjoins was broken for 7.3. Did you come across anything obviously wrong with its queries? As written the queries did not know anything about schemas or the newer reg* data types, e.g. this: Does the latter produce the desired result? Not sure. My oldest note saying it was busted predates the invention of the new reg* types, I think. And while schema awareness is nice, it's not critical to the usefulness of the script: we're only really going to use it for checking the stuff in pg_catalog. So I'm not at all sure why I made that note. Do you get a plausible set of joins out of your version? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] findoidjoins
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Is it useful to have the reference count and unreferenced counts like currently written, or should I just faithfully reproduce the original behavior (except schema aware queries) using libpq in place of libpgeasy? I'd be inclined to reproduce the original behavior. findoidjoins is pretty slow already, and I don't much want to slow it down more in order to provide info that's useless for the primary purpose. It was only taking about 7 seconds for me on an empty database, but if it's not useful I'll go back to the original output format. It is probably easier to produce that output while looping through the first time versus running a script -- should I do that? The separation between findoidjoins and make_oidjoins_check is deliberate --- this allows for easy hand-editing of the join list to remove unwanted joins before preparing the regression test script (cf the notes in the README about bogus joins). Even though this is an extra manual step, I think it's a better answer than trying to make findoidjoins smart enough to suppress the bogus joins itself. Part of the reason for running findoidjoins is to detect any unexpected linkages, so it should not be too eager to hide things. Also, because the output of findoidjoins *should* be manually reviewed, it's better to put it out in an easy-to-read one-line-per-join format than to put out the finished regression script directly. OK. I'll leave as is. As written the queries did not know anything about schemas or the newer reg* data types, e.g. this: Does the latter produce the desired result? Not sure. My oldest note saying it was busted predates the invention of the new reg* types, I think. And while schema awareness is nice, it's not critical to the usefulness of the script: we're only really going to use it for checking the stuff in pg_catalog. So I'm not at all sure why I made that note. Do you get a plausible set of joins out of your version? Looks plausible. But I guess it will be easier to tell once it produces results in the same format as before. I'll make the changes and send it in to patches. Thanks, Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] findoidjoins
Patch withdrawn by author. --- Joe Conway wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Christopher Kings-Lynne dijo: findoidjoins doens't seem to compile: Seems related to the ripping of libpgeasy out of the main distribution... I believe it's been broken for some time (disremember just why, maybe a schema issue?). I had a TODO item to resurrect it so that we could update the oidjoins regression test, which is sadly out of date for the current system catalogs. If anyone wants to work on that ... I'm not sure I interpreted the intent of findoidjoins just right, but here it is updated for schemas, new reg* types, using SPI instead of libpgeasy, and returning the results as a table function. Any corrections/comments? If there is any interest, I'll polish this up a bit more and submit to patches. Just let me know. (Should qualify as a fix, right?) Thanks, Joe [ application/x-gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] findoidjoins
findoidjoins doens't seem to compile: gmake[1]: Entering directory `/home/chriskl/pgsql-head/contrib/findoidjoins' gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../sr c/interfaces/libpgeasy -I../../src/interfaces/libpq -I. -I../../src/include -c -o findoidjoins.o findoidjoins.c -MMD findoidjoins.c:8: halt.h: No such file or directory findoidjoins.c:9: libpgeasy.h: No such file or directory findoidjoins.c: In function `main': findoidjoins.c:26: warning: implicit declaration of function `halt' findoidjoins.c:29: warning: implicit declaration of function `connectdb' findoidjoins.c:31: warning: implicit declaration of function `on_error_continue' findoidjoins.c:32: warning: implicit declaration of function `on_error_stop' findoidjoins.c:34: warning: implicit declaration of function `doquery' findoidjoins.c:50: warning: implicit declaration of function `get_result' findoidjoins.c:50: warning: assignment makes pointer from integer without a cast findoidjoins.c:60: warning: assignment makes pointer from integer without a cast findoidjoins.c:62: warning: implicit declaration of function `set_result' findoidjoins.c:63: warning: implicit declaration of function `fetch' findoidjoins.c:63: `END_OF_TUPLES' undeclared (first use in this function) findoidjoins.c:63: (Each undeclared identifier is reported only once findoidjoins.c:63: for each function it appears in.) findoidjoins.c:66: warning: implicit declaration of function `reset_fetch' findoidjoins.c:69: warning: implicit declaration of function `unset_result' findoidjoins.c:83: warning: passing arg 2 of `sprintf' makes pointer from integer without a cast findoidjoins.c:107: warning: implicit declaration of function `disconnectdb' gmake[1]: *** [findoidjoins.o] Error 1 gmake[1]: Leaving directory `/home/chriskl/pgsql-head/contrib/findoidjoins' gmake: *** [install] Error 2 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] findoidjoins
Christopher Kings-Lynne dijo: findoidjoins doens't seem to compile: gmake[1]: Entering directory `/home/chriskl/pgsql-head/contrib/findoidjoins' gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../sr c/interfaces/libpgeasy -I../../src/interfaces/libpq -I. -I../../src/include -c -o findoidjoins.o findoidjoins.c -MMD findoidjoins.c:8: halt.h: No such file or directory findoidjoins.c:9: libpgeasy.h: No such file or directory Seems related to the ripping of libpgeasy out of the main distribution... -- Alvaro Herrera (alvherre[a]atentus.com) Uno puede defenderse de los ataques; contra los elogios se esta indefenso ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] findoidjoins
Alvaro Herrera [EMAIL PROTECTED] writes: Christopher Kings-Lynne dijo: findoidjoins doens't seem to compile: Seems related to the ripping of libpgeasy out of the main distribution... I believe it's been broken for some time (disremember just why, maybe a schema issue?). I had a TODO item to resurrect it so that we could update the oidjoins regression test, which is sadly out of date for the current system catalogs. If anyone wants to work on that ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] findoidjoins
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Christopher Kings-Lynne dijo: findoidjoins doens't seem to compile: Seems related to the ripping of libpgeasy out of the main distribution... I believe it's been broken for some time (disremember just why, maybe a schema issue?). I had a TODO item to resurrect it so that we could update the oidjoins regression test, which is sadly out of date for the current system catalogs. If anyone wants to work on that ... I'm not sure I interpreted the intent of findoidjoins just right, but here it is updated for schemas, new reg* types, using SPI instead of libpgeasy, and returning the results as a table function. Any corrections/comments? If there is any interest, I'll polish this up a bit more and submit to patches. Just let me know. (Should qualify as a fix, right?) Thanks, Joe findoidjoins-fix.1.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] findoidjoins
Your patch has been added to the PostgreSQL unapplied patches list at: http://207.106.42.251/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Joe Conway wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Christopher Kings-Lynne dijo: findoidjoins doens't seem to compile: Seems related to the ripping of libpgeasy out of the main distribution... I believe it's been broken for some time (disremember just why, maybe a schema issue?). I had a TODO item to resurrect it so that we could update the oidjoins regression test, which is sadly out of date for the current system catalogs. If anyone wants to work on that ... I'm not sure I interpreted the intent of findoidjoins just right, but here it is updated for schemas, new reg* types, using SPI instead of libpgeasy, and returning the results as a table function. Any corrections/comments? If there is any interest, I'll polish this up a bit more and submit to patches. Just let me know. (Should qualify as a fix, right?) Thanks, Joe [ application/x-gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
