carray_to_bytea?

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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?

On 10/22/15 12:13 PM, Ken Been wrote:

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?

Why not just (bytea) cstring_to_text_with_len(...) ?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Yeah, I thought of that (actually bytea *), but then you have to assume
that bytea and text will always be typedef'ed to the same thing. (Is
casting between different non-void pointer types, even if they are
compatible, a warning/error in C? I can't remember.)

On Thu, Oct 22, 2015 at 5:16 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: