Re: [PATCH] Add get_bytes() and set_bytes() functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Add get_bytes() and set_bytes() functions
Date
Msg-id 53176f5f-0bf4-4dd7-8b23-f2e91338e714@eisentraut.org
Whole thread Raw
In response to Re: [PATCH] Add get_bytes() and set_bytes() functions  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: [PATCH] Add get_bytes() and set_bytes() functions
List pgsql-hackers
On 20.01.25 15:01, Aleksander Alekseev wrote:
>  > This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
>  > ERRCODE_INVALID_PARAMETER_VALUE, for consistency with other similar
>  > errors.
>  >
>  > The bytea -> int[248] cast functions should not be marked as leakproof
>  > -- see the docs on the CREATE FUNCTION page: functions that raise
>  > errors for some input values but not others, are not leakproof. This
>  > is why, for example, the int -> bigint cast is leakproof, but the
>  > bigint -> int cast is not.
>  >
>  > Functions working with int8 values should normally go in
>  > utils/adt/int8.c, not utils/adt/int.c. However, I think that
>  > utils/adt/varlena.c would be a better place for all these functions,
>  > because they have more to do with bytea than integer types, and this
>  > would allow them to be kept together, similar to how all the bit <->
>  > integer cast functions are in utils/adt/varbit.c.
>  >
>  > There's no documentation for these new casts. The obvious place to put
>  > it would be in section 9.5 "Binary String Functions and Operators",
>  > which would be consistent with the idea that these are being regarded
>  > primarily as bytea operations, rather than integer operations (just as
>  > the bit <-> integer casts are documented in 9.6 "Bit String Functions
>  > and Operators").
> 
> Many thanks for your great feedback. Here is the corrected patch.

These casts appear to use a particular endianness, but they don't 
document which one, and there is no explanation anywhere why that one is 
the right one.



pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: XMLDocument (SQL/XML X030)
Next
From: Joe Conway
Date:
Subject: Re: Replace current implementations in crypt() and gen_salt() to OpenSSL