we can't overflow to the next higher units, and we might print the lower
units for MS.

> * Allow holdable cursors in SPI

Brendan Jurd

>
> 		o Allow row and record variables to be set to NULL constants,
> 		  and allow NULL tests on such variables
>
> 		  Because a row is not scalar, do not allow assignment
> 		  from NULL-valued scalars.

floating point.

as a performance enhancement.

Mark Kirkwood

forces a particular relation nonnullable, then we can say that the OR does.
This is worth a little extra trouble since it may allow reduction of
outer joins to plain joins.

> 	o Consider reducing on-disk varlena length from four to two
> 	  because a heap row cannot be more than 64k in length

an opclass for a generic type such as ANYARRAY.  The original coding failed
to check that PK and FK columns were of the same array type.  Per discussion
with Tom Dunstan.  Also, make the code a shade more readable by not trying
to economize on variables.

on platforms that need this.  This is done by only writing past the
previously stored message, if it was longer.

JOIN quals, just like WHERE quals, even if they reference every one of the
join's relations.  Now that we can reorder outer and inner joins, it's
possible for such a qual to end up being assigned to an outer join plan node,
and we mustn't have it treated as a join qual rather than a filter qual for
the node.  (If it were, the join could produce null-extended rows that it
shouldn't.)  Per bug report from Pelle Johansson.

require stdint.h and works for "busted" int64.

remove duplicated tests in timestamp, and complete timestamptz with the tests
that were missing to more closely mirror timestamp.

timestamp_tbl table into the timestamp test.  Also, restore a test that
used to exist as a valid test in the timestamptz test.

detection of tabs are added in the future.

be checked at plan levels below the top; namely, we have to allow for Result
nodes inserted just above a nestloop inner indexscan.  Should think about
using the general Param mechanism to pass down outer-relation variables, but
for the moment we need a back-patchable solution.  Per report from Phil Frost.

to_timestamp():
    - ID for day-of-week
    - IDDD for day-of-year

This makes it possible to convert ISO week dates to and from text
fully represented in either week ('IYYY-IW-ID') or day-of-year
('IYYY-IDDD') format.

I have also added an 'isoyear' field for use with extract / date_part.

Brendan Jurd

	o read global SSL configuration file
	o add GUC "ssl_ciphers" to control allowed ciphers
	o add libpq environment variable PGSSLKEY to control SSL hardware keys

Victor B. Wagner

startup and bgwriter processes), and the -y flag.  It's not used anywhere.

considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct).  The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report.  His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there.  (See the example case added to the join
regression test.)  On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was.  There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not.  It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction.  I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.

Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.

continuously, and requests vacuum runs of "autovacuum workers" to postmaster.
The workers do the actual vacuum work.  This allows for future improvements,
like allowing multiple autovacuum jobs running in parallel.

For now, the code keeps the original behavior of having a single autovac
process at any time by sleeping until the previous worker has finished.

platform-specific result ordering.  Per buildfarm results.

WHERE clauses.  createplan.c is now willing to stick a gating Result node
almost anywhere in the plan tree, and in particular one can wind up directly
underneath a MergeJoin node.  This means it had better be willing to handle
Mark/Restore.  Fortunately, that's trivial in such cases, since we can just
pass off the call to the input node (which the planner has previously ensured
can handle Mark/Restore).  Per report from Phil Frost.

>
> 	o Use LC_TIME for localized weekday/month names, rather than
> 	  LC_MESSAGES
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-11/msg00390.php

had never touched the subject before.

Converting from char using 'D' doesn't make lots of sense, of course.

Report from Brendan Jurd.

can be used by src/tools/fsync/test_fsync.c.

copied-and-pasted text in a more useful location.

> * Clean up casting in /contrib/isn
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00245.php
>

> * Improve logging of prepared statements recovered during startup
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php
>

* Allow SQL-language functions to return results from RETURNING queries
>
>   http://archives.postgresql.org/pgsql-hackers/2006-10/msg00665.php
>