in favor of looking at the flat file copy of pg_database during backend
startup.  This should finally eliminate the various corner cases in which
backend startup fails unexpectedly because it isn't able to distinguish
live and dead tuples in pg_database.  Simplify locking on pg_database
to be similar to the rules used with pg_shadow and pg_group, and eliminate
FlushRelationBuffers operations that were used only to reduce the odds
of failure of GetRawDatabaseInfo.
initdb forced due to addition of a trigger to pg_database.

! authentication.  Use of this environment variable is not
! recommended for security reasons (some operating systems
! allow non-root users to see process environment variables via
! <application>ps</>); instead consider using  the
! <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">).

taken automatically, but this is only true with respect to user tables.

http://www.pgsql.ru/db/mw/msg.html?mid=2045361

change TimeATD to/from Datum macros.

Re-initdb is needed.

for input files rather than <.  This makes error messages, &c. more
expressive.

David Fetter

ownership.

Greg Sabino Mullan

> * Improve psql's handling of multi-line queries

< 	  like towupper().
> 	  like towupper().  However, UTF8 already works with normal
> 	  locales but provides no ordering.

> 	o -Change PL/PgSQL to use palloc() instead of malloc()

verified that AC_TRY_RUN works.

subsequently referenced.

Found by: Coverity
Fixed by: Sean Chittenden

implement the md5() SQL-level function). The old code did the
following:

1. de-toast the datum
2. convert it to a cstring via textout()
3. get the length of the cstring via strlen()

Since we are treating the datum context as a blob of binary data,
the latter two steps are unnecessary. Once the data has been
detoasted, we can just use it as-is, and derive its length from
the varlena metadata.

This patch improves some run-of-the-mill md5() computations by
just under 10% in my limited tests, and passes the regression tests.

I also noticed that md5_text() wasn't checking the return value
of md5_hash(); encountering OOM at precisely the right moment
could result in returning a random md5 hash. This patch corrects
that. A better fix would be to make md5_hash() only return on
success (and/or allocate via palloc()), but since it's used in
the frontend as well I don't see an easy way to do that.

This would be a completely inappropriate place to apply localization
anyway.

and parsing work in PL/PgSQL:

- memory management is now done via palloc(). The compiled representation
  of each function now has its own memory context. Therefore, the storage
  consumed by a function can be reclaimed via MemoryContextDelete().

  During compilation, the CurrentMemoryContext is the function's memory
  context. This means that a palloc() is sufficient to allocate memory
  that will have the same lifetime as the function itself. As a result,
  code invoked during compilation should be careful to pfree() temporary
  allocations to avoid leaking memory. Since a lot of the code in the
  backend is not careful about releasing palloc'ed memory, that means
  we should switch into a temporary memory context before invoking
  backend functions. A temporary context appropriate for such allocations
  is `compile_tmp_cxt'.

- The ability to use palloc() allows us to simply a lot of the code in
  the parser. Rather than representing lists of elements via ad hoc
  linked lists or arrays, we can use the List type. Rather than doing
  malloc followed by memset(0), we can just use palloc0().

- We now check that the user has supplied the right number of parameters
  to a RAISE statement. Supplying either too few or too many results in
  an error (at runtime).

- PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we
  do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this
  means we need to be quite lax in what the PL/PgSQL grammar considers
  a "SQL statement". This can lead to misleading behavior if there is a
  syntax error in the function definition, since we assume a malformed
  PL/PgSQL construct is a SQL statement. Furthermore, these errors were
  only detected at runtime (when we tried to execute the alleged "SQL
  statement" via SPI).

  To rectify this, the patch changes the parser to invoke the main SQL
  parser when it sees a string it believes to be a SQL expression. This
  means that synctically-invalid SQL will be rejected during the
  compilation of the PL/PgSQL function. This is only done when compiling
  for "validation" purposes (i.e. at CREATE FUNCTION time), so it should
  not impose a runtime overhead.

- Fixes for the various buffer overruns I've patched in stable branches
  in the past few weeks. I've rewritten code where I thought it was
  warranted (unlike the patches applied to older branches, which were
  minimally invasive).

- Various other minor changes and cleanups.

- Updates to the regression tests.

nochar:
    /* nothing */
    ; /* semicolon required because a goto has to be attached to a statement */

macros around strings that were missing them.

> 	* Add internationalized message strings

+ # Determine if printf supports %1$ argument selection, e.g. %5$ selects
+ # the fifth argument after the printf print string.
+ # This is not in the C99 standard, but in the Single Unix Specification (SUS).
+ # It is used in our langauge translation strings.

Nicolai Tufar with configure changes by Bruce.

8.0.X.

Backpatch to 8.0.X which doesn't work right now.

< * Add the client IP address to pg_stat_activity
> * Add the client IP address and port to pg_stat_activity

Viktor Vislobokov

< * Allow server configuration parameters to be remotely modified
> * Allow pg_hba.conf settings to be controlled via SQL
>
>   This would require a new global table that is dumped to flat file for
>   use by the postmaster.  We do a similar thing for pg_shadow currently.
>

point to its new location.

< * Consider use of open/fcntl(O_DIRECT) to minimize OS caching
> * Consider use of open/fcntl(O_DIRECT) to minimize OS caching,
>   especially for WAL writes