observation by David Fetter.

values as postgresql.conf.

> 	o Add "auto" expanded mode that outputs in expanded format if
> 	  "wrapped" mode can't wrap the output to the screen width
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php
>

> 	o Add option to wrap column values at whitespace boundaries,
>           rather than chopping them at a fixed width.
> 	  Currently, "wrapped" format chops values into fixed
> 	  widths.  Perhaps the word wrapping could use the same
> 	  algorithm documented in the W3C specification.
> 	  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php
> 	  http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

laser <laserlist@pgsqldb.com> with some editorization by me.

As the buffer could now be a lot larger than before, and copying it could
thus be a lot more expensive than before, use strcpy instead of memcpy to
copy the query string, as was already suggested in comments. Also, only copy
the PgBackendStatus struct and string if the slot is in use.

Patch by Thomas Lee, with some changes by me.

space is tracked via GetMemoryChunkSpace, there's really no advantage
to duplicating datumCopy's innards here.  This is one bit of my toast
indirection patch that should go in anyway.

it ought to conform to the rest of palloc.h in using Size for sizes.

of any lower outer join, even if it also references the non-nullable side and
so could not get pushed below the outer join anyway.  We need this in case
the clause is an OR clause: if it doesn't get marked outerjoin_delayed,
create_or_index_quals() could pull an indexable restriction for the nullable
side out of it, leading to wrong results as demonstrated by today's bug
report from toruvinn.  (See added regression test case for an example.)

In principle this has been wrong for quite a while.  In practice I don't
think any branch before 8.3 can really show the failure, because
create_or_index_quals() will only pull out indexable conditions, and before
8.3 those were always strict.  So though we might have improperly generated
null-extended rows in the outer join, they'd get discarded from the result
anyway.  The gating factor that makes the failure visible is that 8.3
considers "col IS NULL" to be indexable.  Hence I'm not going to risk
back-patching further than 8.3.

Hiroshi Saito

taking the maximum of any child rel's width, we should weight the widths
proportionally to the number of rows expected from each child.  In hindsight
this is obviously correct because row width is really a proxy for the total
physical size of the relation.  Per discussion with Scott Carey (bug #4264).

values to libpq.

>
> * Fix system views like pg_stat_all_tables to use set-returning
>   functions, rather than views of per-column functions

truly distinct version of IF.  Per suggestion from Marko Kreen.

vintage Linux is even more broken than we realized: a link to libreadline
will succeed, and fail only at runtime.  It seems that an AC_TRY_RUN test
is the only reliable way to check whether this is really safe.  Per report
from Tatsuo.

appear in a paragraph.

Andy Anderson

>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01890.php

wasn't working.

and non-C locale. Fix is just to use correct source's length for char2wchar
call.

* Improve server security options

  http://archives.postgresql.org/pgsql-hackers/2008-04/msg01875.php
  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00000.php

postmaster.opts.

>
> * Improve LDAP authentication configuration options
>
>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php

patterns, for clarity.

to suppress zero-padding of "name" entries in indexes.

The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name.  In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that.  I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment.  Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.

The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient.  This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.

These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.

< 	o Prevent pg_dump/pg_restore from being affected by
> 	o -Prevent pg_dump/pg_restore from being affected by

Per buildfarm results.

>
> 	o Allow COPY to report errors sooner
>
>          http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php

Joshua D. Drake

> * Allow custom variables to appear in pg_settings()

* Implement a module capability for loading /contrib-style extensions

  http://archives.postgresql.org/pgsql-patches/2008-04/msg00164.php

binary values.

Add comments to libpq C function for parameter passing.

* Consider whether duplicate keys should be sorted by block/offset

  http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php

Create new "Sorting" TODO section.

formatting.c to use common code;  remove duplicate functions and support
routines that are no longer needed.

in pg_proc.  Also make it not emit duplicate extern declarations, and make it
a bit more bulletproof in some other small ways.  Likewise fix the equally
hard-wired, and utterly undocumented, knowledge in the MSVC build scripts.
For testing purposes and perhaps other uses in future, pull out that portion
of the MSVC scripts into a standalone perl script equivalent to
Gen_fmgrtab.sh, and make it generate actually identical output, rather than
just more-or-less-the-same output.

Motivated by looking at Pavel's variadic function patch.  Whether or not
that gets accepted, we can be sure that pg_proc's column set will change
again in the future; it's time to not have to deal with this gotcha.