of different types than the underlying column. The capability isn't yet
used for anything, but will be required by upcoming patch to analyze
tsvector columns.

Jan Urbanski

one for client-side, restoring the previous behaviour with different
sort order for the 'log' level. Also, remove redundant list of available
options, since the enum code will output it automatically.

timezone setting in the current year and for 100 years back, rather than
always examining years 1904-2004.  The original coding would have problems
distinguishing zones whose behavior diverged only after 2004; which is a
situation we will surely face sometime, if it's not out there already.

In passing, also prevent selection of the dummy "Factory" timezone, even
if that's exactly what the system is using.  Reporting time as GMT seems
better than that.

backend.  If so, send a LOG message to the postmaster log, and if the table
is beyond the vacuum-for-wraparound horizon, forcibly drop it.  Per recent
discussions.  Perhaps we ought to back-patch this, but it probably needs
to age a bit in HEAD first.

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()