>> assuming this sideeffect is removed, though?
>
>I have no problem with the hashtable, only with preloading it with
>everything.  What I'd like to see is that the table inherited at fork()
>contains just the data for the default timezone.  (At least in the
>normal case where that setting hasn't been changed since postmaster
>start.)

Here's a patch doing this. Changes score_timezone not to use pg_tzset(),
and thus not loading all the zones in the cache. The actual timezone
being picked will be set using set_global_timezone() which in turn calls
pg_tzset() and loads it in the cache.

Magnus Hagander

test=# \d e
       Table "public.e"
 Column |  Type   | Modifiers
--------+---------+-----------
 i      | integer | not null
 j      | integer | not null
 k      | integer |
Indexes:
    "e_pkey" PRIMARY KEY, btree (i, j), tablespace "haha"
    "ei" btree (i)
    "ej" btree (j), tablespace "haha"
    "ek" btree (k)
Tablespace: "haha"

Qingqing Zhou

Pavel Stehule

< * -Add BETWEEN ASYMMETRIC/SYMMETRIC
> * -Add BETWEEN SYMMETRIC/ASYMMETRIC

> * -Add BETWEEN ASYMMETRIC/SYMMETRIC

EXPLAIN output.

Jean-Paul Argudo

it is sufficient to track whether a backend holds a lock or not, and
store information about transaction vs. session locks only in the
inside-the-backend LocalLockTable.  Since there can now be but one
PROCLOCK per lock per backend, LockCountMyLocks() is no longer needed,
thus eliminating some O(N^2) behavior when a backend holds many locks.
Also simplify the LockAcquire/LockRelease API by passing just a
'sessionLock' boolean instead of a transaction ID.  The previous API
was designed with the idea that per-transaction lock holding would be
important for subtransactions, but now that we have subtransactions we
know that this is unwanted.  While at it, add an 'isTempObject' parameter
to LockAcquire to indicate whether the lock is being taken on a temp
table.  This is not used just yet, but will be needed shortly for
two-phase commit.

Euler Taveira de Oliveira
Matthias Schmidt

> 	o -Have SHOW ALL show descriptions for server-side variables

Matthias Schmidt

< 	o Have SHOW ALL and pg_settings show descriptions for server-side variables
> 	o Have SHOW ALL show descriptions for server-side variables

        o Have SHOW ALL and pg_settings show descriptions for server-side variables

reason is that it's required (more or less) in order to build the latest
DBD::Pg code and I was testing that out under MSVC.

Andrew Dunstan

part of service principal.  If not set, any service principal matching
an entry in the keytab can be used.

NEW KERBEROS MATCHING BEHAVIOR FOR 8.1.

Todd Kover

> 	o -Allow PL/PgSQL's RAISE function to take expressions

if geqo_rand() returns exactly 1.0, resulting in failure due to indexing
off the end of the pool array.  Also, since this is using inexact float math,
it seems wise to guard against roundoff error producing values slightly
outside the expected range.  Per report from bug@zedware.org.

recovery after crash (power loss etc) it may say that it can't restore
index and index should be reindexed.

Some refactoring code.

instead of just scalar variables. Add regression tests and update the
documentation. Along the way, remove some redundant error checking
code from exec_stmt_perform().

Original patch from Pavel Stehule, reworked by Neil Conway.

constraint while determining whether the index sort order matches the
query's ORDER BY.  This for example allows an index on (x,y) to match
	... WHERE x = 42 ORDER BY y;
It only works for btree indexes, but since those are the only ones we
currently have that are ordered at all, that's good enough for now.
Per popular demand.

> * -Use index to restrict rows returned by multi-key index when used with

Lorne Sunley

fix two grammatical errors, and print the INTO target of EXECUTE INTO
if one is specified.

nonconsecutive columns of a multicolumn index, as per discussion around
mid-May (pghackers thread "Best way to scan on-disk bitmaps").  This
turns out to require only minimal changes in btree, and so far as I can
see none at all in GiST.  btcostestimate did need some work, but its
original assumption that index selectivity == heap selectivity was
quite bogus even before this.

mode to only affect the presentation of normal query results, not the
output of psql slash commands. Documentation updated. I also made
some unrelated minor psql cleanup. Per suggestion from Stuart Cooper.

reference page for SQL commands, so that the link text is italicized.

a descriptor that uses the current transaction snapshot, rather than
SnapshotNow as it did before (and still does if INV_WRITE is set).
This means pg_dump will now dump a consistent snapshot of large object
contents, as it never could do before.  Also, add a lo_create() function
that is similar to lo_creat() but allows the desired OID of the large
object to be specified.  This will simplify pg_restore considerably
(but I'll fix that in a separate commit).

configure options are documented.  Per Michael Glaesemann.

syntax for database connection parameters. It has been inside an
#ifdef NOT_USED block since 2001 or so and is marked as "broken", so
I don't think it is likely to be rehabilitated any time soon.

patch adds missing checks to the call sites of malloc(), strdup(),
PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates
the documentation. Per original report from Volkan Yazici about
PQmakeEmptyPGresult() not checking for malloc() failure.

in its own right.  As proposed by Simon Riggs, but with some editorializing
of my own.

code beautification too.

Andreas Seltenreich

These contain the SQLSTATE and error message of the current exception,
respectively. They are scope-local variables that are only defined
in exception handlers (so attempting to reference them outside an
exception handler is an error). Update the regression tests and the
documentation.

Also, do some minor related cleanup: export an unpack_sql_state()
function from the backend and use it to unpack a SQLSTATE into a
string, and add a free_var() function to pl_exec.c

Original patch from Pavel Stehule, review by Neil Conway.

Andreas Seltenreich

history customizable through a variable named HISTFILE, analogous to
psql's already implemented HISTCONTROL and HISTSIZE variables, and
bash's HISTFILE-Variable.

The motivation was to be able to get psql to maintain separate
histories for separate databases.  This is now easily achievable
through a line like the following in ~/.psqlrc:

\set HISTFILE ~/.psql_history-:DBNAME

Andreas Seltenreich