Skip site navigation (1) Skip section navigation (2)

Re: Open 7.1 items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Open 7.1 items
Date: 2001-01-28 04:14:07
Message-ID: 200101280414.XAA28389@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
I assume this addresses the open item:

	Fix for pg_dump of bad system tables

I will remove it from the list.  Thanks.



> At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
> >> Fix for pg_dump of bad system tables
> >
> >Ok. I have made patches for fixing some of pg_dump problems(see
> >attached patches). The patches address the problem with user defined
> >functions, operators and aggregates. 
> 
> These have now been applied with minor modifications.
> 
> 
> >However I have not address what Tom Lane said yet(actually I do not
> >understand what he says).
> >
> >> The other flavor of problems that pg_dump
> >> has in this area are in doing inner joins across system catalogs ...
> 
> This refers to things like:
> 
>         SELECT c.relname 
>         FROM pg_index i, pg_class c 
>         WHERE i.indrelid = %s
>         AND   i.indisprimary 
>         AND   c.oid = i.indexrelid
> 
> ie. where two or more relations are crossed (pg_index and pg_class in this
> case). It assumes that the metadata is valid, and will not highlight
> missing data in the secondary table. We should be doing outer joins:
> 
>         SELECT c.relname 
>         FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid
>         WHERE i.indrelid = %s
>         AND   i.indisprimary 
> 
> and checking for nulls using PQgetisnull. I have actually done this for a
> couple of SELECTs (including the above one), and marked all the others as
> 'XXXX: use LOJ'. There are only 2 or 3 more, but they require a little more
> thought (an inderstanding) before I change them.
> 
> In my view this should be considered a 'work-in-progress' and not hold up
> 7.1 since the problem has been there for a long time.
> 
> 
> ----------------------------------------------------------------
> Philip Warner                    |     __---_____
> Albatross Consulting Pty. Ltd.   |----/       -  \
> (A.B.N. 75 008 659 498)          |          /(@)   ______---_
> Tel: (+61) 0500 83 82 81         |                 _________  \
> Fax: (+61) 0500 83 82 82         |                 ___________ |
> Http://www.rhyme.com.au          |                /           \|
>                                  |    --________--
> PGP key available upon request,  |  /
> and from pgp5.ai.mit.edu:11371   |/
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-hackers by date

Next:From: Philip WarnerDate: 2001-01-28 04:23:27
Subject: Re: Open 7.1 items
Previous:From: Philip WarnerDate: 2001-01-28 03:50:42
Subject: Re: Open 7.1 items

pgsql-jdbc by date

Next:From: Philip WarnerDate: 2001-01-28 04:23:27
Subject: Re: Open 7.1 items
Previous:From: Philip WarnerDate: 2001-01-28 03:50:42
Subject: Re: Open 7.1 items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group