worked and someone asked about them, so we might as well document them.

make the LDAP code's error messages look like they were written by someone
who had heard of our style guidelines.

The original coding stored the raw parser output (ColumnDef and TypeName
nodes) which was ugly, bulky, and wrong because it failed to create any
dependency on the referenced datatype --- and in fact would not track type
renamings and suchlike.  Instead store a list of column type OIDs in the
RTE.

Also fix up general failure of recordDependencyOnExpr to do anything sane
about recording dependencies on datatypes.  While there are many cases where
there will be an indirect dependency (eg if an operator returns a datatype,
the dependency on the operator is enough), we do have to record the datatype
as a separate dependency in examples like CoerceToDomain.

initdb forced because of change of stored rules.

just doesn't work with Bison 2.0 ... fix it ...

during parse analysis, not only errors detected in the flex/bison stages.
This is per my earlier proposal.  This commit includes all the basic
infrastructure, but locations are only tracked and reported for errors
involving column references, function calls, and operators.  More could
be done later but this seems like a good set to start with.  I've also
moved the ReportSyntaxErrorPosition logic out of psql and into libpq,
which should make it available to more people --- even within psql this
is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.

Most of the changes add the mandatory USING clause to DROP OPERATOR
CLASS statements.  DROP TYPE is now DROP TYPE CASCADE; without
CASCADE a DROP TYPE fails due to the circular dependency on the
type's I/O functions.  The DROP FUNCTION statements for the I/O
functions have been removed, as DROP TYPE CASCADE removes them
automatically. Patch from Michael Fuhr.

include file in the same area,.

derived from Jan's.

similar constants if they were not previously defined. All these
constants must be defined by limits.h according to C89, so we can
safely assume they are present.

case where we run low on array slots before we run low on memory is much
more probable than I had thought, and so it's important to treat each
tape fairly in that case.  To fix this, track per-tape slot allocations
just like we track per-tape space allocation.  Also, in the FINALMERGE
code path avoid scanning all the input tapes when we really only need to
read from one.  This should fix poor behavior with very large work_mem
as exhibited by Stefan Kaltenbrunner.
I didn't do anything about putting an upper bound on the number of tapes,
but maybe we should still consider that.

with not responding to query cancel during the last stage of btree index
creation.

var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp()
are just renamings of the historical Postgres aggregates variance() and
stddev() -- the latter names have been kept for backward compatibility.
This patch includes updates for the documentation and regression tests.
The catversion has been bumped.

NB: SQL2003 requires that DISTINCT not be specified for any of these
aggregates. Per discussion on -patches, I have NOT implemented this
restriction: if the user asks for stddev(DISTINCT x), presumably they
know what they are doing.

Otherwise you can't cancel queries like select ... from generate_series(1,1000000).

boilerplate, with approval of author.

tapes) for each merge step.  This will give us some idea of how effective
the merge distribution algorithm is.

performance issue during regular merge passes not only the 'final merge'
case.  The original design contemplated that there would never be more
than about one free block per 'tape', hence no need for an efficient
method of keeping the free blocks sorted.  But given the later addition
of merge preread behavior in tuplesort.c, there is likely to be about
work_mem worth of free blocks, which is not so small ... and for that
matter the number of tapes isn't necessarily small anymore either.  So
we'd better get rid of the assumption entirely.  Instead, I'm assuming
that the usage pattern will involve alternation between merge preread
and writing of a new run.  This makes it reasonable to just add blocks
to the list without sorting during successive ltsReleaseBlock calls,
and then do a qsort() when we start getting ltsGetFreeBlock() calls.
Experimentation seems to confirm that there aren't many qsort calls
relative to the number of ltsReleaseBlock/ltsGetFreeBlock calls.

we are doing the final merge pass on-the-fly, and not writing the data
back onto a 'tape', the number of free blocks in the tape set will become
large, leading to a lot of time wasted in ltsReleaseBlock().  There is
really no need to track the free blocks anymore in this state, so add a
simple shutoff switch.  Per report from Stefan Kaltenbrunner.

process not in the postmaster) and with the right GucSource (needs to
be a nontransactional source since we've not started an xact yet).

(respectively) to rename yylex and related symbols.  Some were doing
it this way already, while others used not-too-reliable sed hacks in
the Makefiles.  It's all nice and consistent now.

not likely ever to be implemented seeing it's been removed from SQL2003.
This allows getting rid of the 'filter' version of yylex() that we had in
parser.c, which should save at least a few microseconds in parsing.

	escape_string_warning = on

> * -Eventually enable escape_string_warning and standard_conforming_strings