it wants to release.  This leads to a race condition: does the backend
that's trying to flush the buffer do so before the one that's deleting the
relation does so?  Usually no problem, I expect, but on occasion this could
lead to hard-to-reproduce complaints from md.c, especially mdblindwrt.

returns a list of RelOptInfos, eliminating the need for static state
in index_info.  That static state was a direct cause of coredumps; if
anything decided to elog(ERROR) partway through an index_info search of
pg_index, the next query would try to close a scan pointer that was
pointing at no-longer-valid memory.  Another example of the reasons to
avoid static state variables...

of the index it wants to destroy.  This ensures that no other backend is
actively scanning or updating that index.  Getting exclusive access on
the index alone is NOT sufficient, because the executor is rather
cavalier about getting locks on indexes --- see ExecOpenIndices().
It might be better to grab index locks in the executor, but I'm not
sure the extra lockmanager traffic is really worth it just to make
index_destroy cleaner.

(whoever thought world-writable files were a good default????).  Modify
the pg_pwd code so that pg_pwd is created with 600 permissions.  Modify
initdb so that permissions on a pre-existing PGDATA directory are not
blindly accepted: if the dir is already there, it does chmod go-rwx
to be sure that the permissions are OK and the dir actually is owned
by postgres.

inval.c thought it could safely use the catcache to look up the OIDs of
system relations.  Not good, considering that inval.c could be called
during catcache loading, if a shared-inval message arrives.  Rip out the
lookup logic and instead use the known OIDs from pg_class.h.

as that test finishes --- helps to give the impression that something is
happening...

to be accepted, but constraints regress test was expecting it to fail.

table defaults or rules: translate them to a function call so that
parse_coerce doesn't reduce them to a date or time constant immediately.
Also, eliminate a lot of redundancy in the expression grammar by
defining a new nonterminal com_expr, which contains all the productions
that can be shared by a_expr and b_expr.

script.  This is way cool...

Jan

compressed lztext data type.

Jan

HAVE the required OID's first.

Jan

Jan

Warn_restart has been set by the backend main loop.  This means that
elog(ERROR) or elog(FATAL) in the postmaster or during backend startup
now have well-defined behavior: proc_exit() rather than coredump.
In the case of elog() inside the postmaster, I think that proc_exit()
is probably not enough --- don't we want our child backends to be
forced to quit too?  But I don't understand Vadim's recent changes in
this area, so I'll leave it to him to look over and tweak if needed.

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.

and pg_amop have indexes.

versions of gmake.

descriptions enabled.

circumstances:
=> select * from foo\x\t\pset border 0 \p\g\\select * from bar;

Also the release prep update so the sql_help.h is generated before
packaging.

Peter.

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.

* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.

I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)

In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.


The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.


So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.

        -Peter

--
Peter Eisentraut                  Sernanders vaeg 10:115

Fewer calls to nameout.

Better use of RelationGetRelationName.