From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Kirk Wolak <wolakk(at)gmail(dot)com>, Eric Radman <ericshane(at)eradman(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add function to_oct |
Date: | 2023-08-22 14:26:08 |
Message-ID: | 20230822142608.GA651404@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 22, 2023 at 04:20:02PM +0200, Peter Eisentraut wrote:
> On 20.08.23 17:25, Nathan Bossart wrote:
>> > Doing a quick test, shows that this changes the current behaviour,
>> > because all inputs are now treated as 64-bit:
>> >
>> > HEAD:
>> >
>> > select to_hex((-1234)::int);
>> > to_hex
>> > ----------
>> > fffffb2e
>> >
>> > With patch:
>> >
>> > select to_hex((-1234)::int);
>> > to_hex
>> > ------------------
>> > fffffffffffffb2e
>> Good catch. In v8, I fixed this by first casting the input to uint32 for
>> the 32-bit versions of the functions. This prevents the conversion to
>> uint64 from setting the rest of the bits. AFAICT this behavior is pretty
>> well defined in the standard.
>
> What standard?
C99
> I don't understand the reason for this handling of negative values. I would
> expect that, say, to_hex(-1234) would return '-' || to_hex(1234).
For this patch set, I was trying to retain the current behavior, which is
to return the two's complement representation. I'm open to changing this
if there's agreement on what the output should be.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-08-22 14:39:35 | Re: Oversight in reparameterize_path_by_child leading to executor crash |
Previous Message | Aleksander Alekseev | 2023-08-22 14:26:04 | Re: Make error messages about WAL segment size more consistent |