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
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 |
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 |