| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | 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:20:02 |
| Message-ID: | 0161f4fa-5cd4-ea9b-01a6-8b6b535bd812@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
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).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-08-22 14:24:09 | Re: list of acknowledgments for PG16 |
| Previous Message | Nathan Bossart | 2023-08-22 14:06:23 | Re: add timing information to pg_upgrade |