Hi Peter,
Thanks for the feedback.
> I think these functions do about three things at once, and I don't think
> they address the originally requested purpose very well.
The amount of things that the function does is a matter of
interpretation. I can claim that it does one thing ("extracts an
integer from a bytea"), or as many things as there are lines of code.
IMO the actual question is whether this is a good user interface or
not. Since we already have get_byte() / set_byte() the interface is
arguably OK.
> Converting between integers and byte arrays of matching size seems like
> reasonable functionality. (You can already do one half of that by
> calling int2send(), int4send(), and int8send(), but the other direction
> (intXrecv()) is not user-callable).
>
> The other things are extracting that byte array from a larger byte array
> and sticking it back into a larger byte array; those seem like separate
> operations. There is already substr() for bytea for the first part, and
> there might be another string-like operationg for the second part, or
> maybe we could add one.
If I understand correctly, you propose doing (1):
```
SELECT substr('\x1122334455667788'::bytea, 2, 2) :: int2;
```
... instead of:
```
SELECT get_bytes('\x1122334455667788'::bytea, 1, 2)
```
... and (2):
```
WITH vals AS (
SELECT '\x1122334455667788'::bytea AS x
) SELECT substr(x, 1, 1) || int2send(1234::int2) || substr(x, 4, 5) FROM vals;
```
... instead of:
```
SELECT set_bytes('\x1122334455667788'::bytea, 1, 2, 0xAABB);
```
There is nothing to do for query (2), it already works. It's not much
better than the query from my first email though.
To clarify, supporting bytea<->integer (and/or bytea<->numeric) casts
doesn't strike me as a terrible idea but it doesn't address the issue
I'm proposing to solve.
--
Best regards,
Aleksander Alekseev
