In passing, fix breakage for case where PGCLIENTENCODING is set in
environment.

command status at the interactive level.  SPI_processed, etc are set
in the same way as the returned command status would have been set if
the same querystring were issued interactively.  Per gripe from
Michael Paesold 25-Sep-02.

as per recent pghackers discussions.  initdb forced due to change in
fields of stored Query nodes.

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