functions with OUT parameters.  The various PLs still need work, as does
pg_dump.  Rudimentary docs and regression tests included.

change saves a great deal of space in pg_proc and its primary index,
and it eliminates the former requirement that INDEX_MAX_KEYS and
FUNC_MAX_ARGS have the same value.  INDEX_MAX_KEYS is still embedded
in the on-disk representation (because it affects index tuple header
size), but FUNC_MAX_ARGS is not.  I believe it would now be possible
to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet.
There are still a lot of vestigial references to FUNC_MAX_ARGS, which
I will clean up in a separate pass.  However, getting rid of it
altogether would require changing the FunctionCallInfoData struct,
and I'm not sure I want to buy into that.

output ordering.

never-yet-vacuumed relation.  This restores the pre-8.0 behavior of
avoiding seqscans during initial data loading, while still allowing
reasonable optimization after a table has been vacuumed.  Several
regression test cases revert to 7.4-like behavior, which is probably
a good sign.  Per gripes from Keith Browne and others.

Andrew Dunstan

Roland Volkmann

whether or not it is a security definer. Changing a function's strictness
is required by SQL2003, and the other capabilities make sense. Also, allow
an optional RESTRICT noise word to be specified, for SQL conformance.

Some trivial regression tests added and the documentation has been
updated.

Formerly, if such a clause contained no aggregate functions we mistakenly
treated it as equivalent to WHERE.  Per spec it must cause the query to
be treated as a grouped query of a single group, the same as appearance
of aggregate functions would do.  Also, the HAVING filter must execute
after aggregate function computation even if it itself contains no
aggregate functions.

	UNICODE => UTF8
	ALT => WIN866
	WIN => WIN1251
	TCVN => WIN1258

The old codes continue to work.

Iijima, reviewed by Neil Conway. Catalog version number bumped,
regression tests updated.

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.

works (and max_stack_depth is not set too high for the platform).
Inspired by trouble report from Brian Betts.

as valid input (it was previously treated as 0). This input was deprecated
in 8.0 (and a warning was emitted). Regression tests updated.

form of CASE (eg, CASE 0 WHEN 1 THEN ...) can be constant-folded as it
was in 7.4.  Also, avoid constant-folding result expressions that are
certainly unreachable --- the former coding was a bit cavalier about this
and could generate unexpected results for all-constant CASE expressions.
Add regression test cases.  Per report from Vlad Marchenko.

tests. Contributed by Koju Iijima, review from Neil Conway, Gavin Sherry
and Tom Lane.

Also, fix error in description of WITH CHECK OPTION clause in the CREATE
VIEW reference page: it should be "CASCADED", not "CASCADE".

estimate to less than the number of values estimated for any one grouping
Var, as suggested by Manfred.  This is intuitively right, and what's
more it puts the plan choices in the subselect regression test back the
way they were before ...

clamp the estimated number of groups to table row count over 10, instead
of table row count; this reflects a heuristic that people probably won't
group over a near-unique set of columns, and the knowledge that we don't
currently have any way to estimate the correlation of the columns better
than guessing.  This change creates a trivial plan change in one of the
regression tests.

command.  This is useful because we can allow truncation of tables
referenced by foreign keys, so long as the referencing table is
truncated in the same command.

Alvaro Herrera

Tom.

constraints on domain types are properly enforced, even if the newly
added column has no default value. Per bug #1433.

pass if "default_with_oids" is set to false. I took the approach of
explicitly adding WITH OIDS to the CREATE TABLEs where necessary, rather
than tweaking the default_with_oids GUC var.

an untyped literal in the CASE's test expression. This adds test
coverage for a bug that was fixed by Tom on January 12.

per Andrew Dunstan.  Also, don't override the user's value of PGHOST
in the 'make installcheck' case.  I think the latter was an ill-considered
workaround for the Windows code back when libpq didn't properly default
to localhost on Unix-socket-less platforms.

few 'listen_addresses' as possible --- on most systems, none at all,
just the Unix socket.  This avoids spurious check failures due to bogus
DNS setups, and is probably a good idea from a security standpoint anyway.
Per trouble report from Jean-GÅrard Pailloncy.

GetTransactionSnapshot() to ensure ActiveSnapshot advances properly.
Sigh.  Extend regression test so it reveals this error too.

advancing ActiveSnapshot when we are inside a volatile function.
Per example from Gaetano Mendola.  Add a regression test to catch
similar problems in future.

the row types of parent/child tables.

exit status in multiline traps.

better make sure the sort order is totally specified; else we get burnt
by platform-specific behavior of qsort() with equal keys.  Per buildfarm
results.

In particular, there was a mathematical tie between the two possible
nestloop-with-materialized-inner-scan plans for a join (ie, we computed
the same cost with either input on the inside), resulting in a roundoff
error driven choice, if the relations were both small enough to fit in
sort_mem.  Add a small cost factor to ensure we prefer materializing the
smaller input.  This changes several regression test plans, but with any
luck we will now have more stability across platforms.

a relation's number of blocks, rather than the possibly-obsolete value
in pg_class.relpages.  Scale the value in pg_class.reltuples correspondingly
to arrive at a hopefully more accurate number of rows.  When pg_class
contains 0/0, estimate a tuple width from the column datatypes and divide
that into current file size to estimate number of rows.  This improved
methodology allows us to jettison the ancient hacks that put bogus default
values into pg_class when a table is first created.  Also, per a suggestion
from Simon, make VACUUM (but not VACUUM FULL or ANALYZE) adjust the value
it puts into pg_class.reltuples to try to represent the mean tuple density
instead of the minimal density that actually prevails just after VACUUM.
These changes alter the plans selected for certain regression tests, so
update the expected files accordingly.  (I removed join_1.out because
it's not clear if it still applies; we can add back any variant versions
as they are shown to be needed.)

of minus zero.  Per Andrew Dunstan.

We don't really want to start a new SPI connection, just keep using the old
one; otherwise we have memory management problems as illustrated by
John Kennedy's bug report of today.  This requires a bit of a hack to
ensure the SPI stack state is properly restored, but then again what we
were doing before was a hack too, strictly speaking.  Add a regression
test to cover this case.

clause implicitly whenever one is not given explicitly.  Remove concept
of a schema having an associated tablespace, and simplify the rules for
selecting a default tablespace for a table or index.  It's now just
(a) explicit TABLESPACE clause; (b) default_tablespace if that's not an
empty string; (c) database's default.  This will allow pg_dump to use
SET commands instead of tablespace clauses to determine object locations
(but I didn't actually make it do so).  All per recent discussions.