Sorting for the inet data type randomly returns the wrong result
when you have networks with the same prefix, but different netmasks.

This is due to the fact that occassionally there is random
(uninitialized?)
data in the extra bits past the point where the netmask cares about
them.

ie (real data from a real live database):

  10.0/10 == 00001010.00100000.00100000.00011000
  10.0/11 == 00001010.00000000.00000000.00000000
                        ^ Bad data, normally never seen

The v4bitncmp() function was only taking one bit length argument so
it would determine that the networks were different, even though
they really aren't (and the netmask test wouldn't be used).  This
ONLY happens if the tuple with the longer bit length is used as the
ip_bits() for the v4bitncmp call AND there happens to be junk data
in place in the shorter tuple.  Odd and random, but I saw it happen
a couple times so...

Ryan Mooney

*** empty log message ***

Add SQL_ASCII encoding test case

Forgot to run autoconf.
(Configure shouldn't really be in CVS ...)

Added configure test for readline's filename_completion_function
Completed psql's \? help

*** empty log message ***

*** empty log message ***

*** empty log message ***

*** empty log message ***

*** empty log message ***

Apply a MATERIAL node to the result of an uncorrelated subplan, if it
looks like it will save computation to do so.

Hmm, it seems nodeMaterial has been broken for a good long while;
closing a relcache entry more times than you open it is not cool.

Patch for Irix from Mark Dalphin.

More fixes for psql ^C handling, especially during copy. Still doesn't
cope so well with copy to but that will have to wait for the next release.

Also added -X option to prevent reading .psqlrc startup file.

New plperl Makefile.

Add QNX fixes from Kardos, Dr. Andreas

equalAttr() had its strcmp test backwards :-(

Small performance improvement in comparetup_heap.

*** empty log message ***

Change reindex command to work properly with gist/hash/rtree

Simplify parsing of column constraints by treating constraint attributes
as independent clauses in the grammar.  analyze.c takes care of putting
the data where it belongs and complaining about invalid combinations.
Also, make TEMP (and TEMPORARY) non-reserved words.

Remove using puts() to print messages. Instead use TPRINTF.

Changed execution time of ON <event> RESTRICT referential
integrity triggers to after statement allways. Ignores
deferred state now, closer to SQL3 semantics.

Jan

autoconf

Update ecpg to use snprintf

Update HISTORY file.

Update TODO list.

Fix comment spacing.

update to 6.40.0009 and provide WIN32 defines for auto-configured items
such as BLCKSZ and MAXPGPATHLEN?

remove extra include.

missing state transition

Looks like I broke SET variable = DEFAULT awhile ago.  Ooops.

Correct bogus syntax in SET example.

Avoid a little bit of unnecessary computation in canonicalize_qual.

Update TODO list.

Add lztext to TypeCategory so that lztext OP text cases will work
correctly (the lztext value will be promoted to text automatically).

Jan forgot to increment catversion when adding lztext.  Naughty naughty.

Update history

Reactivated LZTEXT data type and changed rule plan- and qual-strings
into lztext.

Jan

Update expected files due to the psql format change

Suppress unneccesary message from createdb

Add SQL_ASCII test case

Fix multibyte regress results for EUC_CN, EUC_KR and EUC_TW

Add LinuxPPC mappings

Clean up badly-formatted error messages from pg_connect.

Add Assert() to check for trying to heap_close a relation when the
relcache entry's reference count is zero.

Add 'volatile' declarations to silence gcc warnings about longjmp.
Shouldn't create any portability problems, since we have a configure
test to #define away volatile if the compiler doesn't support it.

Minor improvements in regprocout() and oidvectortypes().

Fix poorly worded error messages for unary operator type resolution
failures.  Fix some outright bugs too, including a reference to
uninitialized memory that would cause failures like this one:
select -('1234567890.1234567'::text);
ERROR:  Unable to locate type oid 2139062143 in catalog

Clean up dependencies for version.o.
This avoids the useless rebuild of pg_version that used to happen on
each build or install pass.

Clean up dependencies for version.o.

Clean up dependencies for version.o.

Fix a couple of inconsistent usages of include <...> vs. include "...".

Add 7.0 changes to HISTORY file.  This has to go into SGML eventually,
but we should get it out to beta testers.

Add date and time datatype handling to convert_to_scalar.  (I was waiting
for Thomas to do the datetime consolidation before touching this, but
it's done now...)

Change rule dumper to produce reasonable output for casts that assign
a specific length or precision, such as foo::char(8).  Remove erroneous
removal of user-written casts at the top level of a SELECT target item.

Fix exprTypmod to recognize length-coercion function expressions,
such as bpchar(char_expression, N), and pull out the attrtypmod that
the function is coercing to.  This allows correct deduction of the
column type in examples such as
CREATE VIEW v AS SELECT f1::char(8) FROM tbl;
Formerly we labeled v's column as char-of-unknown-length not char(8).
Also, this change causes the parser not to insert a redundant length
coercion function if the user has explicitly casted an INSERT or UPDATE
expression to the right length.

psql's \d command wasn't doing the right things with 'char' (type 18)
fields, nor with bpchar and varchar fields that have typmod -1.  The
latter effectively have an unspecified length, so I made them display
as char() and varchar() rather than falsely equating them to char(1)
and varchar(1).

I had managed to break acceptance of "char", which worked in 6.5 to
refer to the single-byte char type.  7.0 was taking it as bpchar(1).

Undo a couple of mistaken applications of NameStr() to StringInfos.
It worked, because they both have fields named 'data', but it's surely
trouble waiting to happen.  I wonder whether there are more ...

Shared-memory hashtables have non-extensible directories, which means
it's a good idea to choose the directory size based on the expected
number of entries.  But ShmemInitHash was using a hard-wired constant.
Boo hiss.  This accounts for recent report of postmaster failure when
asking for 64K or more buffers.

*** empty log message ***

*** empty log message ***

Update TODO list.

Fix longstanding bug that kept functional indexes from working when you
defaulted the opclass.  This addresses TODO item
* Allow creation of functional indexes to use default types
(Does that make it a feature?  Oh dear...)

Enabled regression driver to run without PGLIB set.

Suppress timespan and datetime ops from being brought in via pg_dump
from previous release.

Add missing files like foreign key regression tests and config.h.win32.

  The following is required in order to make beta1 compile on the Win32
platform (psql and libpq):

The file "config.h.win32" in the include\ directory (from my patch from
2000-01-18) is missing from the tree. It needs to be put back :-)

The following patch has to be applied in the interfaces\libpq directory.

//Magnus

Tweak libpq so that if a backend ERROR message arrives while libpq
thinks the connection is idle, the error message is displayed as if
it were a NOTICE.  This seems better than dropping the message on
the floor ... particularly if the message is the backend telling us
why it's about to close the connection.  The previous behavior was
Backend message type 0x45 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
which is not real helpful.

Check pending cancel request before waiting for lock

Add the check CommonSpecialPortal in use(my fault)

Add numeric <-> int8 and numeric <-> int2 conversion functions, as well
as a unary minus operator for numeric.  Now that long numeric constants
will get converted to NUMERIC in early parsing, it's essential to have
numeric->int8 conversion to avoid 'can't convert' errors on undecorated
int8 constants.  Threw in the rest for completeness while I was in the
area.
I did not force an initdb for this, since the system will still run
without the new pg_proc/pg_operator entries.  Possibly I should've.

Make make_const() check the size and precision of a T_Float Value,
and produce either FLOAT8 or NUMERIC output depending on whether the
value fits in a float8 or not.  This is almost back to the way the
code was before I changed T_Float, but there is a critical difference:
now, when a numeric constant doesn't fit in float8, it will be treated
as type NUMERIC instead of type UNKNOWN.

int8in failed to detect overflow; it really should.

Fix plpsql for bsdi.

*** empty log message ***

1. miscadmin.h needs to include sys/types.h for a definition of pid_t

2. Regression tests fail for types int2 and int4 (which can easily be
fixed by adding entries to resultmap) aswell as float8 and geometry,
where floating point numbers appear to be rounded a little differently
than in your expected results (besides that I also need the positive
zeros file). I'm including a patch for the first 2, but I don't know
whether the latter two are actually a bug in postgres or a bug in the
OS or even allowed difference. I'm including my results for reference.

Rolf Grossmann

Well, here's the first pass on regression
tests for the Foreign Key support in 7.0 which
was made against a CVS copy from this
afternoon.

This modifies
 src/test/regress/sql/run_check.tests
 src/test/regress/sql/alter_table.sql
 src/test/regress/expected/alter_table.out
 src/test/regress/sql/foreign_key.sql
 src/test/regress/expected/foreign_key.out

sszabo@bigpanda.co

*** empty log message ***

Update TODO list.

Update TODO list.

Change cancel while waiting-for-lock stuff.

Update TODO list.

First post-beta1 bug fix :-(.  Silly typo in new coding for doNegate
failed to negate a negative value back to positive, so '- - 123.45'
did the wrong thing.

Quick hack solution so that pg_dump of views works.  Needs repair after
Thomas gets back, but better this than nonfunctional pg_dump in the beta.

Fixed psql's Control-C handling when COPY in progress

Oops, commited a test version of this file by accident.  Revert.

Change parse-time representation of float literals (which include oversize
integers) to be strings instead of 'double'.  We convert from string form
to internal representation only after type resolution has determined the
correct type for the constant.  This eliminates loss-of-precision worries
and gets rid of the change in behavior seen at 17 digits with the
previous kluge.

To avoid confusion during early beta testing, commit the current rules
test output as expected output.  We'll probably want to change this again
after something's done about the verbosity of column alias display.

Update TODO list.

Clean up temp file in 'make clean'.

Avoid race conditions in detection of EINPROGRESS during connect().

Jan

Fix "Invalid XID in t_cmin" error in vacuum.

Clean up some really grotty coding in catcache.c, improve hashing
performance in catcache lookups.

fix the TODO
* Allow PQrequestCancel() to terminate when in waiting-for-lock state
Changes are limited to BACKEND,however.

Fixes for \encoding command.
1) freeing null pointer
2) invalid encoding info may be stored into psql variable
3) fix indentation

Update discussion of aggregate syntax to mention ALL.

Update SELECT documentation to have a more thorough discussion
of LIMIT, and fix a few other glitches too.

Tweak planner to use OFFSET+LIMIT, not just LIMIT, as estimate of the
portion of the query result that will be retrieved.  As far as I could
tell, the consensus was that we should let the planner do the best it
can with a LIMIT query, and require the user to add ORDER BY if he
wants consistent results from different LIMIT values.