On Thu, 15 Aug 2024 13:58:03 +0300
Aleksander Alekseev <aleksan...@timescale.com> wrote:
> Hi,
>
> > Perhaps we should also add casts between bytea and the integer/numeric
> > types. That might be easier to use than functions in some
> > circumstances.
> >
> > When casting a numeric to an integer, the result is rounded to the
> > nearest integer, and NaN/Inf generate errors, so we should probably do
> > the same here.
>
> Yes, I was also thinking about adding NUMERIC versions of get_bytes()
> / set_bytes(). This would allow converting more than 8 bytes to/from
> an integer. I dropped this idea because I thought there would be not
> much practical use for it. On the flip side you never know who uses
> Postgres and for what purpose.
>
> I will add corresponding casts unless the idea will get a push-back
> from the community. IMO the existence of these casts will at least not
> make things worse.
When we add such casts between bytea and the integer/numeric types,
one of the problems mentioned the first of the thread, that is,
"we don't have a convenient way of casting a bytea to an integer / bigint
and vice versa", would seem be resolved.
On the other hand, I suppose get_bytes() and set_bytes() are still useful
for extracting bytes from byteas, etc. If casting is no longer the main
purpose of these functions, are variations that get_bytes returns bytea
instead of bigint, and set_bytes receives bytea as the newvalue argument
useful? I wonder it would eliminate the restrict that size cannot be larger
than 8.
Here are my very trivial comments on the patch.
+ * this routine treats "bytea" as an array of bytes.
Maybe, the sentence should start with "This ... ".
+ while(size)
+ {
I wonder inserting a space after "while" is the standard style.
Regards,
Yugo Nagata
--
Yugo Nagata <nag...@sraoss.co.jp>
