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

(Configure shouldn't really be in CVS ...)

Completed psql's \? help

looks like it will save computation to do so.

closing a relcache entry more times than you open it is not cool.

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.

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.

integrity triggers to after statement allways. Ignores
deferred state now, closer to SQL3 semantics.

Jan

such as BLCKSZ and MAXPGPATHLEN?

correctly (the lztext value will be promoted to text automatically).

into lztext.

Jan