Alex Pilosov <alex@pilosoft.com> writes:
> Function to cast bytea as text, I think, should do proper checking that
> input did not contain nulls, and return text data back.
That is most definitely not good enough. In MULTIBYTE installations
you'd have to also check that there were no illegal multibyte sequences.
The whole approach seems misguided to me anyway. bytea isn't equivalent
to text and conversion functions based on providing incomplete binary
equivalence are fundamentally wrong. hex or base64 encode/decode
functions seem like reasonable conversion paths, or you could provide
a function that mimics the existing I/O conversions for bytea, ugly as
they are.
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.
regards, tom lane