Re: [PATCH] by request: base64 for bytea
От | Marko Kreen |
---|---|
Тема | Re: [PATCH] by request: base64 for bytea |
Дата | |
Msg-id | 20010626001635.A4454@l-t.ee обсуждение исходный текст |
Ответ на | Re: [PATCH] by request: base64 for bytea (Alex Pilosov <alex@pilosoft.com>) |
Список | pgsql-hackers |
On Sun, Jun 24, 2001 at 06:20:39PM -0400, Alex Pilosov wrote: > On Sun, 24 Jun 2001, Tom Lane wrote: > > In the case that Marko is describing, it seems to me he is providing > > two independent sets of encryption functions, one for text and one > > for bytea. That they happen to share code under the hood is an > > implementation detail of his code, not a reason to contort the type > > system. If someone wanted to add functions to encrypt, say, polygons, > > would you start looking for ways to create a binary equivalence between > > polygon and text? I sure hope not. > > Well, encrypt/decrypt are special kinds of functions. When the data is > decrypted, its type is not known, as it is not stored anywhere in the > data. Caller is responsible to casting the result to whatever he needs to, > thus, there must be some way to cast output of decrypted data to any type. > > I may be going a bit too far, but, if you think about it, if one wanted to > encrypt a generic type t, these ar e the alternatives: [ ... bunch of good ideas ... ] I do not want to go that far and imagine current encrypt() as something low-level, that encrypts a unstructured array of 8bit values. That makes bytea as 'natural' type to use for it. I now took the Tom suggestion that all functions do not operate well on 8bit values - so now I declared that all my funtions that _do_ operate on 8bit values, get data as bytea. Btw, the length is preserved - I use padding if needed. But no additional info is preserved. Now, if you want to do something higher-level, in POV of PostgreSQL - to attach type data or something else, you can very well build some higher-level functions on encrypt() that add some additional structure for it. This is easy - you can do it in SQL level if you want, but I also tried to make all crypto stuff accesible from C level too. I do not think it belongs to current encrypt() - this is 'next level'. So I do not worry about encrypting polygons yet. Tho' current encrypt() has some 'negative' points on crypto POV. As it does basically pure cipher, and has no structure I cant use some higher features as key generation, attaching algorithm info to data and checksums. (Actually it _does_ support attaching a MD or HMAC to encrypted data, but I consider it as too hackish). So, ee, someday, when I have more time I would like to use current code as building block and do a minimal OpenPGP implementation that does support all of it. This again does not offer anything for 'generic types', but again I do not consider it job for that level. > This may be going a bit too far, since original question only dealt with > text-bytea conversions, but maybe its time to look at 'generic' functions > which return generic types. I did want to encrypt() etc. to operate on 'text' too, as it would be _very_ convinient, and they really are similar on POV of encrypt(). Hmm, on the other hand - Idea for 'generic types', taking account of PostgreSQL current type system - functions: pack(data::whatever)::bytea,unpack_text(data::bytea)::text,unpack_polygon(data::bytea)::polygon... pack() does a compact representation of data, with type attached unpack*() checks if it is of correct type and sane. It may be textual but this takes much room, binary is probably not portable. Eg. it could be done using *in(), *out() functions, maybe even keep the '\0', and prepends type info (oid/name). So later it could be given to encrypt()... ? -- marko
В списке pgsql-hackers по дате отправления: