From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: [PATCH] Add get_bytes() and set_bytes() functions |
Date: | 2025-01-22 18:44:52 |
Message-ID: | 53176f5f-0bf4-4dd7-8b23-f2e91338e714@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2025-01-22 18:59:56 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Previous Message | Robert Treat | 2025-01-22 18:41:10 | Re: XMLDocument (SQL/XML X030) |