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...

One, it now returns the previous hook. That way people don't have to dig
around in libpq-int.h for that information anymore. It previously
returned void, so there should be no incompatibilities.

Second, you cannot set the callback to NULL anymore. (Of course you can
still call it with NULL just to get the current hook.) The way libpq uses
the callback pointer, having a NULL there wasn't very healthy.

Peter Eisentraut

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.

might think ... in fact doesn't do much of anything at the moment ...

pg_dump and interfaces/odbc still need some work.)

fix recently applied to backend's lexer).  I see that YY_USES_REJECT
still gets defined for this lexer, which means it's going to have trouble
parsing really long tokens.  Not sure if it's worth doing anything about
that or not; I don't have the interest right now to understand why
ecpg's additions to the syntax cause this problem...

TODO list.

Vince

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.