Re: findoidjoins

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

Tom Lane wrote:
> 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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-09-04 17:24:16 Re: HISTORY updated, 7.3 branded
Previous Message Iavor Raytchev 2002-09-04 17:14:34 Re: [pgaccess-developers] the current 'schema' tab - renaming ideas

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-09-04 22:05:40 Re: fix for palloc() of user-supplied length
Previous Message Bruce Momjian 2002-09-04 17:05:44 Re: Bug #756: suggestion: file with password instead of $PGPASSWORD