> 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
are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
timing, I know :)) At the moment the digest() function returns
hexadecimal coded hash, but I want it to return pure binary. I
have also included functions encode() and decode() which support
'base64' and 'hex' encodings, so if anyone needs digest() in hex
he can do encode(digest(...), 'hex').
Main reason for it is "to do one thing and do it well" :)
Another reason is if someone needs really lot of digesting, in
the end he wants to store the binary not the hexadecimal result.
It is really silly to convert it to hex then back to binary
again. As I said if someone needs hex he can get it.
Well, and the real reason that I am doing encrypt()/decrypt()
functions and _they_ return binary. For testing I like to see
it in hex occasionally, but it is really wrong to let them
return hex. Only now it caught my eye that hex-coding in
digest() is wrong. When doing digest() I thought about 'common
case' but hacking with psql is probably _not_ the common case :)
Marko Kreen
Bruce Momjian
Tom Lane