Re: [PATCH] by request: base64 for bytea

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