print the index key variable or expression for that column.  It was mistakenly
printing ASC/DESC/NULLS FIRST/NULLS LAST decoration too --- and not only for
the target column, but all columns.  Someday we should have an option to
extract that info (and the opclass decoration as well) for a single index
column ... but today is not that day.  Per bug #3829 and subsequent
discussion.

test outputs.

Andrew Dunstan

proposal by Simon Riggs, though not exactly his patch.

The zero-point case is sensible so far as the data structure is concerned,
so maybe we ought to allow it sometime; but right now the textual input
routines for these types don't allow it, and it seems that not all the
functions for the types are prepared to cope.
Report and patch by Merlin Moncure.

* Consider having the background writer update the transaction status
  hint bits before writing out the page

  Implementing this requires the background writer to have access to system
  catalogs and the transaction status log.

Fix lots of bad markup, bad English, bad explanations.

Last ones ... whew.  Man, that was tedious.

fsync_methods.

Magnus.

lst_hoe01@kwsoft.de

Per complaint from Richard Evans

  Makefile:171: *** Invalid target;  use postgres-A4.pdf or postgres-US.pdf as targets.  Stop.

difference between Julian and Gregorian reckoning of when JD 0 was.

suggesting proper target names.

per Oleg.

psql's \d commands and other uses of printQuery().  Previously we would pass
these strings through gettext() and then send them to the server as literals
in the SQL query.  But the code was not set up to handle doubling of quotes in
the strings, causing failure if a translation attempted to use the wrong kind
of quote marks, as indeed is now the case for (at least) the French
translation of \dFp.  Another hazard was that gettext() would translate to
whatever encoding was implied by the client's LC_CTYPE setting, which might be
different from the client_encoding setting, which would probably cause the
server to reject the query as mis-encoded.  The new arrangement is to send the
untranslated ASCII strings to the server, and do the translations inside
printQuery() after the query results come back.  Per report from Guillaume
Lelarge and subsequent discussion.

faulty code in third arm of #if.  Per buildfarm reports.

>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php

<
< * Allow free-behind capability for large sequential scans to avoid
<   kernel cache spoiling
<
<   Posix_fadvise() can control both sequential/random file caching and
<   free-behind behavior, but it is unclear how the setting affects other
<   backends that also have the file open, and the feature is not supported
<   on all operating systems.

usual 'merge join'.