an identifier :-(.  Sloppy transmission of a patch, likely.

FATAL 1:btree: BTP_CHAIN flag was expected

should be faster.

This makes no difference to the optimizer, which has already decided what
it's gonna do, but it makes the output of EXPLAIN much more plausible.

sometimes estimating an index scan of a table to be cheaper than a
sequential scan of the same tuples...

from ever returning a path.  This put a bit of a crimp in the system's
ability to generate intelligent merge-join plans...

before going into queue behind person with higher piority.

Jan

that, but it'd be a New Feature, wouldn't it ... in the meantime,
avoiding a backend crash seems worthwhile.

Things are better now.

due to lack of check for recursing into a null subexpression.

this is not revealed by any of our regression tests...

Jan

These are no longer used ...

provides string to be used for expected/* files for system specific output...

the database encoding and the client encoding match the encoding expected
by the test.  So, force both of them to be set from the MULTIBYTE
environment var.  This allows regress tests to be run successfully in
multibyte environments other than the compiled-in default.

environments; it was being careless about character lengths.

since multibyte tests fail if it's different from database...

different from database's ...

it failed to cover the case where high bits of char are 100 or 101.
Not sure if fix is right, but it agrees with pg_utf_mblen ... and it
doesn't lock up ...

wording of 'relation does not exist' error message.  Update expected files
accordingly.

but I think it's OK now...

can be generated in a buffer and then sent to the frontend in a single
libpq call.  This solves problems with NOTICE and ERROR messages generated
in the middle of a data message or COPY OUT operation.

 disabled (commented-out) in the code.

pg_proc entries for array I/O routines besides the one detected by the
original patcher.  Tighten type_sanity regress test accordingly.