output.

All the other ones that are primarily a new datatype say "data type for
<purpose>", so make this one similar.

Initially it was called int_aggregate after the old SQL file, but since
the documentation just says "intagg" and that's also the directory name,
let's conform to that instead.

From first pass of testing.  Notably, there seems to be no need for
adminpack--unpackaged--1.0.sql because none of the objects that the
old module creates would ever be dumped by pg_dump anyway (they are
all in pg_catalog).

It was never terribly consistent to use OR REPLACE (because of the lack of
comparable functionality for data types, operators, etc), and
experimentation shows that it's now positively pernicious in the extension
world.  We really want a failure to occur if there are any conflicts, else
it's unclear what the extension-ownership state of the conflicted object
ought to be.  Most of the time, CREATE EXTENSION will fail anyway because
of conflicts on other object types, but an extension defining only
functions can succeed, with bad results.

This isn't fully tested as yet, in particular I'm not sure that the
"foo--unpackaged--1.0.sql" scripts are OK.  But it's time to get some
buildfarm cycles on it.

sepgsql is not converted to an extension, mainly because it seems to
require a very nonstandard installation process.

Dimitri Fontaine and Tom Lane

relative, by creating a function path_is_relative_and_below_cwd() to
check for specific requirements.  It is unclear if this fixes a security
problem or not but the new code is more robust.

This follows recent discussions, so it's quite a bit different from
Dimitri's original.  There will probably be more changes once we get a bit
of experience with it, but let's get it in and start playing with it.

This is still just core code.  I'll start converting contrib modules
shortly.

Dimitri Fontaine and Tom Lane

This follows my proposal of yesterday, namely that we try to recreate the
previous state of the extension exactly, instead of allowing CREATE
EXTENSION to run a SQL script that might create some entirely-incompatible
on-disk state.  In --binary-upgrade mode, pg_dump won't issue CREATE
EXTENSION at all, but instead uses a kluge function provided by
pg_upgrade_support to recreate the pg_extension row (and extension-level
pg_depend entries) without creating any member objects.  The member objects
are then restored in the same way as if they weren't members, in particular
using pg_upgrade's normal hacks to preserve OIDs that need to be preserved.
Then, for each member object, ALTER EXTENSION ADD is issued to recreate the
pg_depend entry that marks it as an extension member.

In passing, fix breakage in pg_upgrade's enum-type support: somebody didn't
fix it when the noise word VALUE got added to ALTER TYPE ADD.  Also,
rationalize parsetree representation of COMMENT ON DOMAIN and fix
get_object_address() to allow OBJECT_DOMAIN.

This adds collation support for columns and domains, a COLLATE clause
to override it per expression, and B-tree index support.

Peter Eisentraut
reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch

KaiGai Kohei

the support functions.

Unlike Btree-based LIKE optimization, this works for non-left-anchored
search patterns.  The effectiveness of the search depends on how many
trigrams can be extracted from the pattern.  (The worst case, with no
trigrams, degrades to a full-table scan, so this isn't a panacea.  But
it can be very useful.)

Alexander Korotkov, reviewed by Jan Urbanski

database, not in the os-user database, per report from Magnus.

contrib/intarray's gettoken() uses a fixed-size buffer to collect an
integer's digits, and did not guard against overrunning the buffer.
This is at least a backend crash risk, and in principle might allow
arbitrary code execution.  The code didn't check for overflow of the
integer value either, which while not presenting a crash risk was still
bad.

Thanks to Apple Inc's security team for reporting this issue and supplying
the fix.

Security: CVE-2010-4015

always 8k writes, per suggestion from Tom.  Also adjust open_sync output
layout.

it is 8k as expected.

Joey Adams

Robert Haas, with a few suggestions from Thom Brown

This is still pretty rough - among other things, the documentation
needs work, and the messages need a visit from the style police -
but this gets the basic framework in place.

KaiGai Kohei

Reduce #includes to minimum actually needed; in particular include
postgres_fe.h not postgres.h, so as to stop build failures on some
platforms.

Use get_progname() instead of hardwired program name; improve error
checking for command line syntax; bring error messages into line with
style guidelines; include strerror result in die() cases.

Per buildfarm.

Un-break Windows build (I hope) by making the HAVE_FSYNC_WRITETHROUGH
code match the backend.  Fix incorrect program help message.  static-ize
all functions.

Actually rename the program, rather than just claiming we did.  Hook it
into the build system.  Get rid of useless dependency on libpq.  Clean up
#include list and messy whitespace.

remove them.  Also other renaming.

No actual change in functionality ... just get rid of uselessly complex
code to pass the number of keys via extra_data.

In particular, make hstore @> '' succeed for all hstores, likewise
hstore ?& '{}'.  Previously the results were inconsistent and could
depend on whether you were using a GiST index, GIN index, or seqscan.