On Thu, Oct 22, 2015 at 4:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Ken Been <kbb...@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?
