bring in missing files ... this isn't very clean, but :(

INSERT ... DEFAULT VALUES statement does indeed have a null targetlist,
at least during parse and rewrite stages.

treat a NULL condition result as FALSE.  Clean up some bogus comments
here and there, too.

error message wording, due to most cases of no-such-relation now being
detected in central heap_open code rather than on an ad-hoc basis.

additional argument specifying the kind of lock to acquire/release (or
'NoLock' to do no lock processing).  Ensure that all relations are locked
with some appropriate lock level before being examined --- this ensures
that relevant shared-inval messages have been processed and should prevent
problems caused by concurrent VACUUM.  Fix several bugs having to do with
mismatched increment/decrement of relation ref count and mismatched
heap_open/close (which amounts to the same thing).  A bogus ref count on
a relation doesn't matter much *unless* a SI Inval message happens to
arrive at the wrong time, which is probably why we got away with this
sloppiness for so long.  Repair missing grab of AccessExclusiveLock in
DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi.
Recommend 'make clean all' after pulling this update; I modified the
Relation struct layout slightly.
Will post further discussion to pghackers list shortly.

See attached mail for more details.

-------------------------------------------------------------------
From: "Vadim Mikheev" <vadim@krs.ru>
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
References: <000201befa94$42fe04c0$2801007e@cadzone.tpf.co.jp>
Subject: Re: elog(ERROR) in vacuum
Date: Fri, 10 Sep 1999 10:27:10 +0900
Organization: OJSC Rostelecom (Krasnoyarsk)
Message-ID: <37D85E6E.5AFA126D@krs.ru>

Hiroshi Inoue wrote:
>
> Hello Vadim,
>
> I have a question about vacuum.
>
> VACUUM has a phase like commit which calls TransactionIdCommit().
> But if elog(ERROR) occured after that,the status of transaction is
> changed from XID_COMMIT to XID_ABORT.
>
> Seems to me this causes inconsistency.
> Shoudn't AbortTransaction() be changed not to call TransacionIdAbort()
> in case of vacuum.

You're right!
As usual -:)

Vadim

into it.

to version 2, and fixes ResultSetMetaData.getColumnDisplaySize().

commit to CVS.

 for v6.5.2 info.

 which do not need to be so for our parser. Apparently omitted earlier.

 Almost worked before, but forgot one place to check.
 Reported by Tatsuo Ishii.
Still does not do the right thing if inserting into a non-string target
 column. Should look for a type coersion later, but doesn't.

message under a kernel that only returns one packet per recv() call.  This
didn't use to matter much, but it starts to get annoying with multi-megabyte
EXPLAIN VERBOSE responses...

conditions.  There are some pretty bogus heuristics in prepqual.c that
try to decide whether to output CNF or DNF format; they need to be replaced,
likely.  Right now the code is probably too willing to choose DNF form,
which might hurt performance in some cases that used to work OK.
But at least we have a foundation to build on.

Make sure both SRCH_INC and SRCH_LIB are checked for existances and added to
the CPPFLAGS/LDFLAGS variables...

cygwin doesn't have an endian.h, but defines BYTE_ORDER in sys/param.h

in or_normalize, remove detection of duplicate subexpressions (since it's
highly unlikely to be worth the amount of time it takes), and introduce
a dnfify() entry point so that unintelligible backwards logic in UNION
processing can be eliminated.  This is just an intermediate step ---
next thing is to look at not forcing the qual into CNF form when it would
be better off in DNF form.

and pg_server_to_client.  Eliminate copy.c's restriction on the length
of a single attribute.

arbitrarily long strings, and frontends should cope gracefully.  Goes
along with long query and long error message changes...

This change seems necessary in conjunction with long queries, and it
cleans up some bogosity in connection with long EXPLAIN texts anyway.
Note that current libpq will accept any length error message (at least
until it runs out of memory); prior versions have a limit of 8K, but
will cleanly discard excess error text, so there shouldn't be any
big compatibility problems with old clients.