Thanks to Tom Lane for ideas.

This fix is reported by Hiroki Kataoka (kataoka@interwiz.koganei.tokyo.jp).

subselects can only appear on the righthand side of a binary operator.
That's still true for quantified predicates like x = ANY (SELECT ...),
but a subselect that delivers a single result can now appear anywhere
in an expression.  This is implemented by changing EXPR_SUBLINK sublinks
to represent just the (SELECT ...) expression, without any 'left hand
side' or combining operator --- so they're now more like EXISTS_SUBLINK.
To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink
type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to.
But the grammar will only generate one for a multiple-left-hand-side
row expression.

versions of gmake.

nulls with non-nulls using proper three-valued boolean logic.  Also clean
up ExecQual to make it clearer that ExecQual *does* follow the SQL spec
for boolean nulls.  See '[BUGS] (null) != (null)' thread around 10/26/99
for more detail.

Fewer calls to nameout.

Better use of RelationGetRelationName.

Now indexes of pg_class and pg_type are unique indexes
and guarantee the uniqueness of correponding attributes.
heap_create() was changed to take another boolean parameter
which allows to postpone the creation of disk file.
The name of rd_nonameunlinked was changed to rd_unlinked.
It is used generally(not only for noname relations) now.
Requires initdb.

unreasonable amount of time to clean up after a vanished parser problem.
Don't call fireRIRonSubselect when we know there are no subselects,
either.

Apparently, back in the dim reaches of prehistory, the parser couldn't
be trusted to label Const nodes with the correct constbyval value ...
and someone preferred to patch around this in copyObject rather than
fix the problem at the source.  The problem is long gone, but the hack
lingered on.  Until now.

indexes to open.  Avoid unnecessary work in ExecCheckPerm, too.

make_const --- don't repeat cache searches that aren't needed.

Thanks to Hiroshi

in the TupleDesc that the caller already has (for call from ExecMain) or
can make just as easily as ExecInitJunkFilter() can (for call from
ExecAppend).  Also, don't bother to build a junk filter for an INSERT
operation that doesn't actually need one, which is the normal case.

mdnblocks.  Bad enough it does an lseek, but to do it twice for no
reason...

that has no subplan --- saves a material amount of time for a simple
INSERT ... VALUES query.

In particular, don't bother to look up type information for attributes
where we're not actually going to use it, and avoid copying entire tlist
structure when it's not necessary.

during initial run formation by keeping both current run and next-run
tuples in the same heap (yup, Knuth is smarter than I am).  And, during
merge passes, make use of available sort memory to load multiple tuples
from any one input 'tape' at a time, thereby improving locality of
access to the temp file.

never to commit without running regress tests...

before calling execProject, when the outerPlan has returned zero tuples.
I took this out under the mistaken impression that the input tuple
couldn't be referenced by execProject if we weren't in GROUP BY mode.
But it can, if we're in an UPDATE or DELETE...

The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:

COMMENT ON [
  [ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname>
|

  COLUMN <relation>.<attribute> |
  AGGREGATE <aggname> <aggtype> |
  FUNCTION <funcname> (arg1, arg2, ...) |
  OPERATOR <op> (leftoperand_typ rightoperand_typ) |
  TRIGGER <triggername> ON relname>

Mike Mascari
(mascarim@yahoo.com)

eliminating some wildly inconsistent coding in various parts of the
system.  I set MAXPGPATH = 1024 in config.h.in.  If anyone is really
convinced that there ought to be a configure-time test to set the
value, go right ahead ... but I think it's a waste of time.

postgres.c's declaration of 'char pg_pathname[...]'.  I dunno when these
ports were last used, but they are sure broken now...

when an initdb-forcing change has been applied within a development cycle.
PG_VERSION serves this purpose for official releases, but we can't bump
the PG_VERSION number every time we make a change to the catalogs during
development.  Instead, increase the catalog version number to warn other
developers that you've made an incompatible change.  See my mail to
pghackers for more info.

pg_dump and interfaces/odbc still need some work.)

This patch fix a TODO list item.
* require SELECT DISTINCT target list to have all ORDER BY columns

example
ogawa=> select distinct x from t1 order by y;
ERROR:  ORDER BY columns must appear in SELECT DISTINCT target list

---
Atsushi Ogawa

23 Jul 99.  Not sure why this didn't get applied before...

logfile.c wanted ... seems easier to fix BufFileSeek.