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

into postgres.c; make sure it happens for all cases that seem to need it.
Perhaps it would be better to explicitly exclude just a few utility
statement types from setting a snapshot?

in our write/flush operation any WAL entries that got queued while we
were waiting to get the WALWriteLock.  This improves throughput when
transactions are small enough that several can be committed per WAL
write (ie, per disk revolution).

false. per Tom Lane's suggestion. See:

Subject: Suggested change to pgbench
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Cc: pgsql-patches@postgreSQL.org
Date: Sun, 06 Oct 2002 12:37:27 -0400

for more details.

> * Add now("transaction|statement|clock") functionality

Also, code < and > as &lt;/&gt; for cleaner SGML.

> * Allow sorting, temp files, temp tables to use multiple work directories

ago.

discussion some weeks ago.  Also, add a check that two types to be
binary-equivalenced match as to typlen, typbyval, and typalign; if
they don't then it's surely a mistake to equivalence them.