On Thu, Oct 22, 2015 at 4:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ken Been <kbbeen@gmail.com> writes: > I'd like to propose a carray_to_bytea function, similar to > cstring_to_text_with_len, declared in src/include/utils.h and implemented > in src/backend/utils/adt/varlena.c. The implementation would be the same > as cstring_to_text_with_len, but with a different return type.
> I have put the implementation in my code, but I'd much prefer to use a > public API with hidden implementation.
Hardly worth it, really. There is nothing to a bytea except the length and the bytes, so I'd say that any "information hiding" you might be getting is illusory. Moreover, such a function would encourage people to assemble useless intermediate copies of the bytestring rather than constructing it directly in the result object. Consider for example what byteacat() would look like if it were required to use such a function.
(To some extent these arguments could also be made to apply to cstring_to_text_with_len, of course, but I consider that to be a sibling of cstring_to_text, which does have considerable usefulness.)
regards, tom lane
All right, well, it's not a big deal for me, but I'll make one last pitch
concerning the usefulness. My input is a byte array with a length. I can't assume zero-termination for varchar fields, so cstring_to_text_with_len is exactly what I need for those. For varbinary (i.e., bytea), you're right, it's just a couple of lines of code, but what if the implementation of struct varlena changes? Are we guaranteed that "palloc(len + VARHDRSZ)" will always allocate the correct amount?