return ((c == 't') || (c == 'T'));
int the getBoolean function on line 184:ish to:
 return ((c == 't') || (c == 'T') (c == '1'));

Hunter Hillegas

public ResultSet getTables(String catalog, String schemaPattern, String

Jeroen van Vianen

Ola Sundell

not properly handle 8-bit unsigned data as it blindly
casts the byte to an int, which java most helpfully
promotes to a signed type.  This causes problems when
you can only return -1 to indicated EOF.

The following patch fixes the bug and has been tested
locally on image data.

Chad David

type never scans a relation directly, it can't be an EPQ target.
Explicitly drop subplan's tuple table to ensure we have no buffer pin
leaks.

with many NULLs ( inserting of NULL into indexed field cause
ERROR: MemoryContextAlloc: invalid request size)
As a workaround 'vacuum analyze' could be used.

This patch resolves the problem, please upply to 7.1.1 sources and
current cvs tree.

Oleg Bartunov

encode - is below.  I even got the linefeed stuff wrong.

--
marko

Re-add pg_index.indisclustered in a minimalist way.  Also fix BSDi
dynamic linker change.  #include must be before #ifdef test.

trees (mostly my fault).  Repair.  Also fix long-standing bug in ExecReplace:
after recomputing a concurrently updated tuple, we must recheck constraints.
Make EvalPlanQual leak memory with somewhat less enthusiasm than before,
although plugging leaks fully will require more changes than I care to risk
in a dot-release.

forced.

for relations on the nullable side of an OUTER JOIN.  For now I think
we'd better refuse such queries.

> Postgres 7.1.0), and I think I've found a bug.
>
> I compiled Pgcrypto with OpenSSL, using gcc 2.95.4 and
> OpenSSL 0.9.6a (the latest Debian 'unstable' packages).

> web=> select encode(digest('blah', 'sha1'), 'base64');
> FATAL 1:  pg_encode: overflow, encode estimate too small
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Succeeded.

> Is this a bug? Can it be fixed?

This is a bug alright.  And a silly one :)

Marko Kreen

not TRUE.  Otherwise we break pl call handler functions.  fmgr_oldstyle
will take care of making sure the semantics are the same for C functions.
Clean up some slightly grotty coding in 7.0 pg_class reading, also.

when we need to move to a new page; as long as we can insert the new
tuple on the same page as before, we only need LockBuffer and not the
expensive stuff.  Also, twiddle bufmgr interfaces to avoid redundant
lseeks in RelationGetBufferForTuple and BufferAlloc.  Successive inserts
now require one lseek per page added, rather than one per tuple with
several additional ones at each page boundary as happened before.
Lock contention when multiple backends are inserting in same table
is also greatly reduced.

needed it.

from our fearless Ultrix porter, Alexander Klimov <ask@wisdom.weizmann.ac.il>