6 Commits (5af4855383494de44f3f62fcaa91e1ea5d0cc8eb)

Author	SHA1	Message	Date
Bruce Momjian	fdbfe1c68e	Well, the correct code - that corresponds to current ... encode - is below. I even got the linefeed stuff wrong. -- marko	25 years ago
Bruce Momjian	5ee76ac8c0	> I've been experimenting with pgcrypto 0.3 (distributed with ... > 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	25 years ago
Bruce Momjian	9e1552607a	pgindent run. Make it all clean.	25 years ago
Tom Lane	d08741eab5	Restructure the key include files per recent pghackers discussion: there ... 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.	25 years ago
Bruce Momjian	659a1d65c6	Well, learned the hard way... ... Marko Kreen	25 years ago
Bruce Momjian	cb5427ee47	I would like to do a interface change in pgcrypto. (Good ... 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	25 years ago