On Sat, 1 Mar 2025 at 11:30, Dean Rasheed wrote:
>
> With those updates, I think this is ready for commit, which I'll do in
> a day or two, if there are no further comments.
>
Committed.
Regards,
Dean
On Fri, 24 Jan 2025 at 13:00, Aleksander Alekseev
wrote:
>
> Thank you. Here is the corrected patch.
>
This looks pretty good to me. I have a just a couple of minor comments:
* The loop in bytea_integer() can be written more simply as a "for"
loop. Given that it's only a few lines of code, it mi
Hi Dean,
> IMO big-endian is the most convenient byte-ordering to use here,
> because then the string representation of the bytea is consistent with
> the hex representation of the integer. It's also consistent with the
> integer-to-bit casts, which output the most significant bits first,
> starti
On Thu, 23 Jan 2025 at 14:30, Aleksander Alekseev
wrote:
>
> Hi Peter,
>
> > 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.
>
> Right, I choose network order / big-endian. I agree tha
Hi Peter,
> 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.
Right, I choose network order / big-endian. I agree that it would make
sense to emphasise this fact in the documentation below
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
Hi Dean,
> 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
On Tue, 14 Jan 2025 at 13:25, Aleksander Alekseev
wrote:
>
> Thanks. I agree that the proposed error messages look nicer than the
> one I used in v6. Here is the corrected patch.
>
This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
ERRCODE_INVALID_PARAMETER_VALUE, for consistency wit
Hi Dean,
> Those are all instances of a value that's outside a specific range
> that you might not otherwise know, rather than being out of range of
> the type itself. For that, we generally don't say what the range of
> the type is. For example, we currently do:
>
> select repeat('1', 50)::bit(50
On Mon, 13 Jan 2025 at 19:23, Alvaro Herrera wrote:
>
> But these don't show the acceptable range. We have these that do:
>
> #: utils/adt/varbit.c:1824 utils/adt/varbit.c:1882
> #, c-format
> msgid "bit index %d out of valid range (0..%d)"
>
> #: utils/adt/varlena.c:3218 utils/adt/varlena.c:3285
On 2025-Jan-13, Dean Rasheed wrote:
> On Mon, 13 Jan 2025 at 17:36, Aleksander Alekseev
> wrote:
> >
> > Besides fixing opr_sanity test I corrected error messages:
> >
> > -ERROR: bytea size 3 out of valid range, 0..2
> > +ERROR: bytea out of valid range, ''..'\x'
>
> "smallint out of rang
On Mon, 13 Jan 2025 at 17:36, Aleksander Alekseev
wrote:
>
> Besides fixing opr_sanity test I corrected error messages:
>
> -ERROR: bytea size 3 out of valid range, 0..2
> +ERROR: bytea out of valid range, ''..'\x'
>
"smallint out of range", "integer out of range" and "bigint out of
range"
Hi Michael,
> v5-0001 includes the following output:
>
> --- a/src/test/regress/expected/opr_sanity.out
> +++ b/src/test/regress/expected/opr_sanity.out
> @@ -126,9 +126,12 @@ WHERE p1.oid < p2.oid AND
> p1.proretset != p2.proretset OR
> p1.provolatile != p2.provolatile OR
> p1.p
On Fri, Oct 18, 2024 at 05:20:42PM +0300, Aleksander Alekseev wrote:
> Rebased, v5.
v5-0001 includes the following output:
--- a/src/test/regress/expected/opr_sanity.out
+++ b/src/test/regress/expected/opr_sanity.out
@@ -126,9 +126,12 @@ WHERE p1.oid < p2.oid AND
p1.proretset != p2.proretse
Hi,
> > I guess there are in fact two problems, not one.
> >
> > 1. Converting between bytea and integer types
> > 2. Multibyte versions of get_byte() / set_byte()
> >
> > As you rightly pointed out, for (1) we just need to add missing casts.
> > Here is the corresponding patch, v3-0001. Note that
Hi,
> I guess there are in fact two problems, not one.
>
> 1. Converting between bytea and integer types
> 2. Multibyte versions of get_byte() / set_byte()
>
> As you rightly pointed out, for (1) we just need to add missing casts.
> Here is the corresponding patch, v3-0001. Note that I couldn't re
Hi,
> On 19.08.24 16:10, Aleksander Alekseev wrote:
> > 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.
>
> What is the issue you are proposing to solve?
>
> You linked to a
On 19.08.24 16:10, Aleksander Alekseev wrote:
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.
What is the issue you are proposing to solve?
You linked to a couple of threads and
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
int
On Fri, 16 Aug 2024 11:41:37 +0300
Aleksander Alekseev wrote:
> Hi,
>
> > 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
On 14.08.24 13:01, Aleksander Alekseev wrote:
The proposed patch adds get_bytes() and set_bytes() functions. The
semantics is similar to get_byte() and set_byte() we already have but
the functions operate with bigints rather than bytes and the user can
specify the size of the integer. This allows
Hi,
> 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_by
On Thu, 15 Aug 2024 13:58:03 +0300
Aleksander Alekseev 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
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
On Thu, 15 Aug 2024 at 05:20, Joel Jacobson wrote:
>
> On Wed, Aug 14, 2024, at 19:25, Joel Jacobson wrote:
> > What do we want to happen if passing a numeric with decimal digits,
> > to decimal_to_bytes()? It must be an error, right?
> >
> > Example: SELECT decimal_to_bytes(1.23);
>
> Hmm, an err
On Wed, Aug 14, 2024, at 19:25, Joel Jacobson wrote:
> What do we want to happen if passing a numeric with decimal digits,
> to decimal_to_bytes()? It must be an error, right?
>
> Example: SELECT decimal_to_bytes(1.23);
Hmm, an error feels quite ugly on second thought.
Would be nicer if all numeri
On Wed, Aug 14, 2024, at 18:31, David Fetter wrote:
> On Wed, Aug 14, 2024 at 05:39:32PM +0200, Joel Jacobson wrote:
>> On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
>> >> I also think it would be nice to provide these convenience functions:
>> >> to_bytes(bigint) -> bytea
>> >> from_bytes(by
On Wed, Aug 14, 2024 at 05:39:32PM +0200, Joel Jacobson wrote:
> On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
> >> I also think it would be nice to provide these convenience functions:
> >> to_bytes(bigint) -> bytea
> >> from_bytes(bytea) -> bigint
> >
> > Along with these, would it make sen
On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
>> I also think it would be nice to provide these convenience functions:
>> to_bytes(bigint) -> bytea
>> from_bytes(bytea) -> bigint
>
> Along with these, would it make sense to have other forms of these
> that won't choke at 63 bits, e.g. NUMERIC
On Wed, Aug 14, 2024 at 02:34:06PM +0200, Joel Jacobson wrote:
> On Wed, Aug 14, 2024, at 13:31, Aleksander Alekseev wrote:
> >> I wonder if get_bytes() and set_bytes() will behave differently
> >> on little-endian vs big-endian systems?
> > No, the returned value will not depend on the CPU endines
On Wed, Aug 14, 2024, at 13:31, Aleksander Alekseev wrote:
>> I wonder if get_bytes() and set_bytes() will behave differently
>> on little-endian vs big-endian systems?
> No, the returned value will not depend on the CPU endiness. Current
> implementation uses big-endian / network order which in my
Hi,
> +1
>
> I wanted this myself many times.
>
> I wonder if get_bytes() and set_bytes() will behave differently
> on little-endian vs big-endian systems?
>
> If so, then I think it would be nice to enforce a consistent byte order
> (e.g., big-endian), to ensure consistent behavior across platfor
On Wed, Aug 14, 2024, at 13:01, Aleksander Alekseev wrote:
> The proposed patch adds get_bytes() and set_bytes() functions. The
> semantics is similar to get_byte() and set_byte() we already have but
> the functions operate with bigints rather than bytes and the user can
> specify the size of the i
33 matches
Mail list logo
