is of type Object, and is null

Dave Cramer

David Esposito

(http://www.ideit.com/products/dbvis/) to work with Postgresql and I found
out the following bug: if database has views then getTables() gets the null
pointer exception ('order by relname' makes the listing tree in
DbVisualizer a lot useful !!)

This patch should propably be applied to the the jdbc1's
DatabaseMetaData.java, too.

Panu Outinen

 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.