Thread: 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
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"
Alvaro Herrera <alvherre@atentus.com> 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
Tom Lane wrote: > Alvaro Herrera <alvherre@atentus.com> 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
Attachment
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 <alvherre@atentus.com> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Joe Conway <mail@joeconway.com> 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
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
Patch withdrawn by author. --------------------------------------------------------------------------- Joe Conway wrote: > Tom Lane wrote: > > Alvaro Herrera <alvherre@atentus.com> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Joe Conway <mail@joeconway.com> 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
Tom Lane wrote: > Joe Conway <mail@joeconway.com> 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