clear on that point.

query that uses it.  This ensures that triggers will be applied consistently
throughout a query even if someone commits changes to the relation's
pg_class.reltriggers field meanwhile.  Per crash report from Laurette Cisneros.
While at it, simplify memory management in relcache.c, which no longer
needs the old hack to try to keep trigger info in the same place over
a relcache entry rebuild.  (Should try to fix rd_att and rewrite-rule
access similarly, someday.)  And make RelationBuildTriggers simpler and
more robust by making it build the trigdesc in working memory and then
CopyTriggerDesc() into cache memory.

- Wrap them in the <database class="table"> tags, since thats what they
are (no markup rules for this, so it inherits from parent -- no style
change)
- Mention that pg_database, pg_shadow, and pg_group are global, and the
rest are local to the specific DB. (I believe this is correct).

> Works for me, though I suppose we could explain what the exceptions are
> like in general terms.  Perhaps something like
>
> 'Most system catalogs are copied from the template database during
> database creation, and are thereafter database-specific.  A few
> catalogs are physically shared across all databases in an installation;
> these are marked in the descriptions of the individual catalogs.'

Ok, new patch.

Rod Taylor

contrib/dbmirror/README.dbmirror doc file.

Neil Conway

ANALYZE is not quite clear when branches of the query are never
executed. So this tiny patch fixes that.

The patch is attached and can also be found at:
http://svana.org/kleptog/pgsql/pgsql-explain.patch

Martijn van Oosterhout

1) pltcl:
Add SPI_freetuptable() calls to avoid memory leaks (Me + Neil Conway)
Change sprintf()s to snprintf()s (Neil Conway)
Remove header files included elsewhere (Neil Conway)

2)plpython:
Add SPI_freetuptable() calls to avoid memory leaks
Cosemtic change to remove a compiler warning


Notes:

I have tested pltcl.c for
 a) the original leak problem reported for the repeated call of spi_exec
in a TCL fragment
and
 b) the subsequent report resulting from the use of spi_exec -array
in a TCL
fragment.

The plpython.c patch is exactly the same as that applied to make
revision 1.23,
the plpython_schema.sql and feature.expected sections of the patch are
also the
same as last submited, applied and subsequently reversed out. It remains
untested by me (other than via make check). However, this should be safe
provided PyString_FromString() _copies_ the given string to make a
PyObject.


Nigel J. Andrews

Per gripe from Patrick Welche, 13-Oct-2002.

It isn't.

one is pushed down into an outer join and the other is not.

> * Rename oid2name to relfilenode2name and install by default

> 	o Allow psql \copy to specify column names

> * -Add pg_backend_pid() function to backend

precision.

vacuum.patch updates ref/vacuum.sgml to explicitly state that an
exclusive lock is not obtained during normal (non-FULL) vacuum.

  Rod Taylor

Added Tom's patch fix for heap_close.

Rod Taylor

   contrib/contrib-global.mk library and _generally_ behave like
   Makefiles for other contrib modules.
   Besides it fixes Perl's interpolation of $libdir variable, which
   should be passed to backend instead. This patch is done against
   PostgreSQL 7.3b2

   Besides, I want to thank Peter Eisentraut for his very friendly and
   helpful attitude and politely ask him to check whether contrib
   modules actually continue to work after he implements another
   major change to their build process.

Alexey Borzov

> > > > found in the postmaster and not included from elsewhere)
> >
> > shared libs on AIX need to be able to resolve all symbols at linkage time.
> > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres
> > executable.
>
> They are defined in backend/utils/mb/conv.c and declared in
> include/mb/pg_wchar.h.  They're also linked into the
> postmaster.  I don't see anything unusual.

Attached is a patch to fix the mb linking problems on AIX. As a nice side effect

it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
(all shlibs that are not postmaster loadable modules).

Please apply to current (only affects AIX).

The _LARGE_FILES problem is unfortunately still open, unless Peter
has fixed it per his recent idea.

Zeugswetter Andreas SB SD

> > I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> > be more or less rewritten completely, and probably should to get rigth
> > all the cases mentioned in the past attisinherited discussion.  Is this
> > desirable for 7.3?  It can probably be hacked around and the rewrite
> > kept for 7.4, but I think it will be much simpler after the rewrite.
>
> If it's a bug then it's fair game to fix in 7.3.  But keep in mind that
> pg_dump has to behave at least somewhat sanely when called against older
> servers ... will your rewrite behave reasonably if the server does not
> offer attinhcount values?

Nah.  I don't think it's worth it: I had forgotten that older versions
should be supported.  I just left the code as is and added a
version-specific test.

This patch allows pg_dump to dump correctly local definition of columns.
In particular,

CREATE TABLE p1 (f1 int, f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c () INHERITS (p1, p2);
ALTER TABLE ONLY p1 DROP COLUMN f1;
CREATE TABLE p3 (f1 int);
CREATE TABLE c2 (f1 int) INHERITS (p3);

Will be dumped as
CREATE TABLE p1 (f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c (f1 int) INHERITS (p1, p2);
CREATE TABLE c2 (f1 int) INHERITS (p3);

(Previous version will dump
CREATE TABLE c () INHERITS (p1, p2)
CREATE TABLE c2 () INHERITS (p3) )

Alvaro Herrera

> 	o Allow SHOW of non-modifiable variables, like pg_controldata