adjust/hashtypes

sha1, md5 and other data types for PostgreSQL

hashtypes's Issues

Adopt PostgreSQL conventions for cast functions

By convention the casting function's name in SQL terms is the same as the data type returned. So we would have:

• md5hash(text)
• md5hash(bytes)

both returning md5hash types. For backwards compatibility would add these in addition to existing functions.

The reason is it makes it easier to remember the names of the functions when calling the functions in this way.

Add binary I/O to the SHA types.

I made an implementation of binary I/O for the various SHA types.

For now, I'm not making it a pull request because my work depends on the Windows port, which is already a pull request.

I bumped the version to 0.1.6 and made an upgrade script based on help from the PostgreSQL General mailing list.

I did not touch the .in files, and copied hashtypes--0.1.5.sql directly. I did not touch sha.sql.type because I don't know how it's used to generate the install script.

PostgreSQL 11 conflict with bytea conversion functions

PostgreSQL 11 introduced sha224, sha256, sha384 and sha512 functions (*) getting and returning bytes that conflict with the identically named bytea to sha- conversion functions from this extension.

The obvious fix is to add append 'b' to the from bytes conversion, making, i..e sha224 to sha224b; that went as far as to be able to create an extension, but the regression tests are still failing.

• https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=10cfce34c0fe20d2caed5750bbc5c315c0e4cc63

Multiple warnings when compiling with new gcc

With gcc-6.4.0 I'm seeing:

x86_64-pc-linux-gnu-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -pipe -fPIC -fPIC -DSHA_NAME=1 -DSHA_LENGTH=20 -I. -I./ -I/usr/include/postgresql-10/server -I/usr/include/postgresql-10/internal  -D_GNU_SOURCE   -c -o src/sha1.o src/sha1.c
src/crc32.c: In function 'crc32_in':
src/crc32.c:22:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   crc32 *out = palloc(sizeof(crc32));
   ^~~~~
src/crc32.c:27:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   long int pout = strtol(in, &p, 16);
   ^~~~
src/crc32.c:38:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
   out = (uint32_t)pout;
       ^
In file included from src/crc32.c:1:0:
src/crc32.c: In function 'crc32_out':
/usr/include/postgresql-10/server/postgres.h:492:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
 #define DatumGetUInt32(X) ((uint32) GET_4_BYTES(X))
                           ^
/usr/include/postgresql-10/server/fmgr.h:235:30: note: in expansion of macro 'DatumGetUInt32'
 #define PG_GETARG_UINT32(n)  DatumGetUInt32(PG_GETARG_DATUM(n))
                              ^~~~~~~~~~~~~~
src/crc32.c:6:31: note: in expansion of macro 'PG_GETARG_UINT32'
 #define PG_GETARG_CRC32(N)    PG_GETARG_UINT32(N)
                               ^~~~~~~~~~~~~~~~
src/crc32.c:47:15: note: in expansion of macro 'PG_GETARG_CRC32'
   crc32 *in = PG_GETARG_CRC32(0);
               ^~~~~~~~~~~~~~~
src/crc32.c:49:25: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'crc32 * {aka unsigned int *}' [-Wformat=]
   snprintf(out, 10, "%08x", in);
                         ^
src/md5.c: In function 'md5_recv':
src/md5.c:78:23: warning: pointer targets in passing argument 2 of 'pq_copymsgbytes' differ in signedness [-Wpointer-sign]
  pq_copymsgbytes(buf, result->bytes, nbytes);
                       ^~~~~~
In file included from src/md5.c:15:0:
/usr/include/postgresql-10/server/libpq/pqformat.h:44:13: note: expected 'char *' but argument is of type 'unsigned char *'
 extern void pq_copymsgbytes(StringInfo msg, char *buf, int datalen);
             ^~~~~~~~~~~~~~~

how about a md5 short type

if we' only store the first 8 chars of the hash we could have an internal length of 8 instead of 16 and should still not have collisions in most cases
@wellle @roa ?