On Tue, Jun 26, 2018 at 11:51:49PM -0700, Andres Freund wrote:
> Looking at surrounding code I found a few more oddities, but of older
> vintage:
> - pq_sendfloat4 uses an uint32 in the union, but float8 uses a int64.
> - same with pq_getmsgfloat[48]
> - pq_getmsgint64 returns a int64, should
Hi,
On 2018-06-14 13:25:30 -0700, Andres Freund wrote:
> On 2018-06-14 16:17:28 -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > How about not renaming the functions, but just change argument types?
>
> Yea, I'm in favor of this. I don't think the 'u' in there would benefit
> us, and the
Hi,
On 2018-06-14 16:17:28 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > How about not renaming the functions, but just change argument types?
Yea, I'm in favor of this. I don't think the 'u' in there would benefit
us, and the cast from signed to unsigned is well defined, so it's safe
to
Alvaro Herrera writes:
> How about not renaming the functions, but just change argument types?
Yeah, I didn't understand why anything else would be on the table.
We already changed their arg types for 11, no? This is just second
thoughts about what to change them to.
Hello
How about not renaming the functions, but just change argument types?
Having to change all callsites to cope with some new naming convention
does not strike me as a great idea ... it may collide with any
backpatching in the area, for one.
--
Álvaro Herrera
On Wed, Jun 13, 2018 at 11:53:21AM -0700, Andres Freund wrote:
> On 2018-06-13 14:10:37 +0900, Michael Paquier wrote:
>> On Mon, Jun 11, 2018 at 02:25:44PM +0900, Michael Paquier wrote:
>>> On top of that it seems to me that we'd want to rename any new
>>> routines to include "uint" in their name
Hi,
On 2018-06-13 22:02:13 +0100, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >> unsigned char x = 128;
> >> pq_sendbyte(, x);
> >>
> >> which I believe is not well-defined since pq_sendbyte takes an int8,
> >> and conversions of unrepresentable values to _signed_
> "Andres" == Andres Freund writes:
>> unsigned char x = 128;
>> pq_sendbyte(, x);
>>
>> which I believe is not well-defined since pq_sendbyte takes an int8,
>> and conversions of unrepresentable values to _signed_ integer types
>> are (iirc) implementation-dependent.
Andres> It's
On 2018-06-13 14:10:37 +0900, Michael Paquier wrote:
> On Mon, Jun 11, 2018 at 02:25:44PM +0900, Michael Paquier wrote:
> > On Wed, Jun 06, 2018 at 12:27:58PM -0400, Alvaro Herrera wrote:
> >> Do you have an answer to this question? Does anybody else?
> >>
> >> (My guts tell me it'd be better to
Hi,
On 2018-05-24 18:13:23 +0100, Andrew Gierth wrote:
> In PG11, pq_sendbyte got changed from taking an int parameter to taking
> an int8.
>
> While that seems to work in general, it does mean that there are now
> several places in the code that do the equivalent of:
>
> unsigned char x =
On Wed, Jun 06, 2018 at 12:27:58PM -0400, Alvaro Herrera wrote:
> Do you have an answer to this question? Does anybody else?
>
> (My guts tell me it'd be better to change these routines to take
> unsigned values, without creating extra variants. But guts frequently
> misspeak.)
My guts are
On 2018-May-24, Andrew Gierth wrote:
> In PG11, pq_sendbyte got changed from taking an int parameter to taking
> an int8.
> Would it be better for these to take unsigned values, or have unsigned
> variants?
Do you have an answer to this question? Does anybody else?
(My guts tell me it'd be
On Thu, May 24, 2018 at 06:13:23PM +0100, Andrew Gierth wrote:
> In PG11, pq_sendbyte got changed from taking an int parameter to taking
> an int8.
From 1de09ad8.
> While that seems to work in general, it does mean that there are now
> several places in the code that do the equivalent of:
>
>
In PG11, pq_sendbyte got changed from taking an int parameter to taking
an int8.
While that seems to work in general, it does mean that there are now
several places in the code that do the equivalent of:
unsigned char x = 128;
pq_sendbyte(, x);
which I believe is not well-defined since
14 matches
Mail list logo
