> > 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.

> * Allow sorting/temp files to use multiple work directories

> * Allow sorting to use multiple work directories

just the significant fields of FunctionCallInfoData, rather than MemSet'ing
the whole struct to zero.  Unused positions in the arg[] array will
thereby contain garbage rather than zeroes.  This buys back some of the
performance hit from increasing FUNC_MAX_ARGS.  Also tweak tuplesort.c
code for more speed by marking some routines 'inline'.  All together
these changes speed up simple sorts, like count(distinct int4column),
by about 25% on a P4 running RH Linux 7.2.

> * Add floor(float8) and other missing functions

are missing the FROM clause (due to a long-ago pg_dump bug).  Patch by
Stephan Szabo, minor tweaking by Tom Lane.

< * Provide automatic running of vacuum in the background (Tom)
> * Provide automatic running of vacuum in the background (Tom) [vacuum]

> * Check GUC geqo_threshold to see if it is still accurate

to avoid unnecessary consumption of semaphores.

test expected output.  Tweak contrib/spi Makefile so that refint.so is
by default built with appropriate NOTICE support for regression testing.

/contrib/vacuumlo

Mario Weilguni

entries, and attributes some JDBC changes to the right people.

Neil Conway

Teodor Sigaev

behavior of connectby() in the presence of infinite recursion. Please
apply this one in addition to the one sent earlier.

Joe Conway

> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
>   if (strstr(branch_delim || branchstr->data || branch_delim,
>                        branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.

Good point. Thank you Masaru for the suggested fix.

Attached is a patch to fix the bug found by Masaru. His example now
produces:

regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
  keyid | parent_keyid | level |  branch

-------+--------------+-------+----------
     11 |              |     0 | 11
     10 |           11 |     1 | 11-10
    111 |           11 |     1 | 11-111
      1 |          111 |     2 | 11-111-1
(4 rows)

While making the patch I also realized that the "no show branch" form of
the  function was not going to work very well for recursion detection.
Therefore  there is now a default branch delimiter ('~') that is used
internally, for  that case, to enable recursion detection to work. If
you need a different  delimiter for your specific data, you will have to
use the "show branch" form  of the function.

Joe Conway

client
utilities (libpq.dll and psql.exe) for win32 (missing defines,
adjustments to
includes, pedantic casting, non-existent functions) per:
   http://developer.postgresql.org/docs/postgres/install-win32.html.

It compiles cleanly under Windows 2000 using Visual Studio .net. Also
compiles clean and passes all regression tests (regular and contrib)
under Linux.

In addition to a review by the usual suspects, it would be very
desirable for  someone well versed in the peculiarities of win32 to take
a look.

Joe Conway

Neil Conway

> * Add schema, cast, and conversion backslash commands to psql

be able to do that, but the ability seems to have got lost in the
shuffle).  Add a -o nextOID switch for completeness.  Improve the
documentation to explain how and why to use these switches.