Re: [HACKERS] Open 7.1 items
От | Philip Warner |
---|---|
Тема | Re: [HACKERS] Open 7.1 items |
Дата | |
Msg-id | 3.0.5.32.20010128145042.02f72ca0@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 7.1 items (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] Open 7.1 items
|
Список | pgsql-jdbc |
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 |/
В списке pgsql-jdbc по дате отправления: