space consumption in pull_args, and avoid doing the full CNF transform on
operands of operator clauses, where it's really not particularly helpful.
This answers the TODO item about large numbers of OR clauses, at least
partially.  I was able to do a ten-thousand-OR-clause query with about
20Mb memory consumption ... it took an obscenely long time, but it worked...

corrects flex myinput() routine so that it doesn't assume there is only
one bufferload of data.  We still have the issue of getting rid of
YY_USES_REJECT so that the scanner can cope with tokens larger than its
initial buffer size.

psql.c seems clean of query length restrictions now.

before comparison; if fields being joined are different widths then hashing
will yield wrong answer.  Also, remove hashjoinable mark from all uses of
array_eq, because array structures may have padding bytes between elements
and the pad bytes are of uncertain content.  This could be revisited if
array code is cleaned up.
Modify opr_sanity regress test to complain if array_eq operator is marked
hashjoinable.

offended my aesthestic sensibility that there was so much unreadable code
doing so little.  Rewritten code is about half the size, faster, and
(I hope) much more intelligible.

current transaction) are not flushed by shared-cache-inval reset message.
SI reset actually works now, for probably the first time in a long time.
I was able to run initdb and regression tests with a 16-element SI message
array, with a lot of NOTICE: cache state reset messages but no crashes.

system tables, but actually there are only 6 --- see RelationInitialize.
Kinda makes you wonder how long ago this code was last executed...

automatically create the file, except during bootstrap mode where that
seems to be necessary.

We can't support these properly, since once the relation's physical files
are unlinked, there's no way to roll back the transaction.  I suppose
we could postpone the unlink till transaction commit, but then what of
BEGIN; DROP TABLE foo; CREATE TABLE foo; ?
The code does allow dropping a table/index created in the current
transaction block, however, since the post-abort state would be that
the table doesn't exist anyway.

real name before doing lookup.  We only want to index temp tables by their
real names in the relcache, to ensure there's not more than one relcache
entry for them.

to be deleted.

pg_class tuple during ALTER TABLE ADD COLUMN.

has positive refcount, it is rebuilt from pg_class data.  This ensures
that relcache entries will track changes made by other backends.  Formerly,
a shared inval report would just be ignored if it happened to arrive while
the relcache entry was in use.  Also, fix relcache to reset ref counts
to zero during transaction abort.  Finally, change LockRelation() so that
it checks for shared inval reports after obtaining the lock.  In this way,
once any kind of lock has been obtained on a rel, we can trust the relcache
entry to be up-to-date.

the SInval spinlock while it is calling the passed invalFunction or
resetFunction.  This is necessary to avoid deadlock with lmgr change;
InvalidateSharedInvalid can be called recursively now.  It should be
a good performance improvement anyway --- holding a spinlock for more
than a very short interval is a no-no.

istm that this would be a job for configure.
Most modern OSes actually use perl5 by default ;)

insight that RelationFlushRelation ought to invoke smgrclose, and that the
way to make that work is to ensure that mdclose doesn't fail if the relation
is already closed (or unlinked, if we are looking at a DROP TABLE).  While
I was testing that, I was able to identify several problems that we had
with multiple-segment relations.  The system is now able to do initdb and
pass the regression tests with a very small segment size (I had it set to
64Kb per segment for testing).  I don't believe that ever worked before.
File descriptor leaks seem to be gone too.
I have partially addressed the concerns we had about mdtruncate(), too.
On a Win32 or NFS filesystem it is not possible to unlink a file that
another backend is holding open, so what md.c now does is to truncate
unwanted files to zero length before trying to unlink them.  The other
backends will be forced to close their open files by relation cache
invalidation --- but I think it would take considerable work to make
that happen before vacuum truncates the relation rather than after.
Leaving zero-length files lying around seems a usable compromise.

 Thanks to Michael Deck <deckm@cleansoft.com> for the tipoff.
Add more examples for language components.

backend.  Still much left to do.

error/notice message lengths, and number of fields per tuple.  Add
pqexpbuffer.c/.h, a frontend version of backend's stringinfo module.
This is first step in applying Mike Ansley's long-query patches,
even though he didn't do any of these particular changes...

robust, since it's about to get used much more heavily.

mkMakefile.tkdefs.sh.in.

and 1370 (timestamp(datetime)).  This does not force an initdb, exactly,
but you won't see the effects of the bug fix until you do one.
BTW, OID 1358 for timespan(time) is still broken:
select timespan('21:11:26'::time);
ERROR:  No such function 'time_timespan' with the specified attributes
But I couldn't figure out what it ought to be defined as, so I left it be.

more verbose results from ruleutils.c changes.

references or CASE expressions, didn't parenthesize complex expressions
properly.  Also, always output variable references as fully qualified
names to eliminate ambiguity bug recently reported.  (This could be
smarter, but reliability comes first.)

Most parts of the planner should ignore, or indeed never even see, uplevel
Vars because they will be or have been replaced by Params.  There were a
couple of places that got it wrong though, probably my fault from recent
changes...

last loop which would return the *first* surviving-to-that-point candidate
regardless of which one actually passed the test.  This was producing
such curious results as 'oid % 2' getting translated to 'int2(oid) % 2'.

documented intepretation of the lefthand and oper fields.  Fix a number of
obscure problems while at it --- for example, the old code failed if the parser
decided to insert a type-coercion function just below the operator of a
SubLink.
CAUTION: this will break stored rules that contain subplans.  You may
need to initdb.

It will keep track the number of pages allocated so that
vacuum could allocate twice of the previous allocation.
This will greatly reduce the total memory consumption of
vacuum.

ALLOC_BIGCHUNK_LIMIT are always allocated as separate malloc() blocks,
and are free()d immediately upon pfree().  Also, if such a chunk is enlarged
with repalloc(), translate the operation into a realloc() so as to
minimize memory usage.  Of course, these large chunks still get freed
automatically if the alloc set is reset.
I have set ALLOC_BIGCHUNK_LIMIT at 64K for now, but perhaps another
size would be better?

constant to a different type.  Not sure that this could happen in ordinary
parser usage, but it can in some new code I'm working on...