near daylight savings time boudaries.  This handles it properly, e.g.

        test=> select '2005-04-03 04:00:00'::timestamp at time zone
        'America/Los_Angeles';
                timezone
        ------------------------
         2005-04-03 07:00:00-04
        (1 row)

function that actually sleeps, instead of busy-waiting.  Perhaps this
will resolve some of the intermittent stats failures we keep seeing.

	test=> select (CURRENT_DATE + '05:00'::time)::timestamp at time zone
	'Canada/Pacific';
	        timezone
	------------------------
	 2005-07-22 08:00:00-04
	(1 row)

	test=> select ('2005-07-20 00:00:00'::timestamp without time zone) at
	time zone 'Europe/Paris';
	        timezone
	------------------------
	 2005-07-19 22:00:00-04

Udpate documentation.

coding would ignore startup cost differences of less than 1% of the
estimated total cost; which was OK for normal planning but highly not OK
if a very small LIMIT was applied afterwards, so that startup cost becomes
the name of the game.  Instead, compare startup and total costs fuzzily
but independently.  This changes the plan selected for two queries in the
regression tests; adjust expected-output files for resulting changes in
row order.  Per reports from Dawid Kuroczko and Sam Mason.

Add SECS_PER_YEAR and MINS_PER_HOUR macros.

<
> * Research storing disk pages with no alignment/padding

Add spaces where needed.
Reference time interval variables as tinterval.

calculations for interval and time/timetz to behave sanely for both
integer and float timestamps; up to now I think it's been doing
something pretty strange...

	#define DAYS_PER_YEAR   365.25
	#define MONTHS_PER_YEAR 12
	#define DAYS_PER_MONTH  30
	#define HOURS_PER_DAY   24

24 hours. This is very helpful for daylight savings time:

	select '2005-05-03 00:00:00 EST'::timestamp with time zone + '24 hours';
	      ?column?
	----------------------
	2005-05-04 01:00:00-04

	select '2005-05-03 00:00:00 EST'::timestamp with time zone + '1 day';
	      ?column?
	----------------------
	2005-05-04 01:00:00-04

Michael Glaesemann

	test=> select '4 months'::interval / 5;
	   ?column?
	---------------
	 1 mon -6 days
	(1 row)

after:

	test=> select '4 months'::interval / 5;
	 ?column?
	----------
	 24 days
	(1 row)

The problem was the use of rint() to round, and then find the remainder,
causing the negative values.

an <xref/>.

for circle(polygon), which was missing; remove bogus entry for
point(lseg, lseg), which does not exist, and the documentation seemed to
describe lseg_interpt, which we already document as an operator not a
function.  Also remove entry for box_intersect, which likewise is
preferentially used via the operator #.

by using LIKE...ESCAPE instead.  Per suggestion by andrew@supernews.

readable, and more like the other places in this file.

Eugen Nedelcu

is applied last, after other constraints such as name patterns.  This
is useful first because the pg_foo_is_visible() functions are relatively
expensive, and second because it minimizes the prospects for race
conditions.  The change is fragile though since it makes unwarranted
assumptions about planner behavior, ie, that WHERE clauses will be
executed in the original order if there's not reason to change it.
This should fix ... or at least hide ... an intermittent failure in the
prepared_xacts regression test, while we think about what else to do.