Re: findoidjoins

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: findoidjoins
Date: 2002-09-04 16:57:53
Message-ID: 17379.1031158673@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-09-04 16:58:25 Re: HISTORY updated, 7.3 branded
Previous Message Brett Schwarz 2002-09-04 16:57:09 Re: [HACKERS] pgaccess - where to store the own data

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-09-04 17:05:44 Re: Bug #756: suggestion: file with password instead of $PGPASSWORD
Previous Message Rod Taylor 2002-09-04 16:48:01 Re: Bug #756: suggestion: file with password instead of