Re: unsigned and signed chars in libpq API

Lists: pgsql-hackers
From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: unsigned and signed chars in libpq API
Date: 2012-02-02 07:33:24
Message-ID: CAAfz9KP04h9t6h6q1=Hh+EUfcyV=os=G1PGqsk8uxt2R-dLt2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hey all,

Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking because a bit confused. How this intermixes with LO's API,
which based on signed chars (although as we all know large object -
is a just bytea splitted on chunks)?
And also PQgetvalue() returns char* rather than unsigned char*.

Thanks.

--
// Dmitriy.


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unsigned and signed chars in libpq API
Date: 2012-08-27 16:21:39
Message-ID: 20120827162139.GM11088@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
> Hey all,
>
> Could you tell me please an objective reason why PQunescapeBytea()
> returns unsigned char* rather than just char* ?
> I am asking because a bit confused. How this intermixes with LO's API,
> which based on signed chars (although as we all know large object -
> is a just bytea splitted on chunks)?
> And also PQgetvalue() returns char* rather than unsigned char*.

Can someone answer this? Are we consistent here?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unsigned and signed chars in libpq API
Date: 2012-08-27 16:40:37
Message-ID: 3517.1346085637@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
>> Could you tell me please an objective reason why PQunescapeBytea()
>> returns unsigned char* rather than just char* ?
>> I am asking because a bit confused. How this intermixes with LO's API,
>> which based on signed chars (although as we all know large object -
>> is a just bytea splitted on chunks)?
>> And also PQgetvalue() returns char* rather than unsigned char*.

> Can someone answer this? Are we consistent here?

We're not, particularly, but changing any of this seems likely to
create more pain than it removes.

regards, tom lane


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unsigned and signed chars in libpq API
Date: 2012-08-27 17:13:56
Message-ID: 20120827171356.GN11088@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Aug 27, 2012 at 12:40:37PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
> >> Could you tell me please an objective reason why PQunescapeBytea()
> >> returns unsigned char* rather than just char* ?
> >> I am asking because a bit confused. How this intermixes with LO's API,
> >> which based on signed chars (although as we all know large object -
> >> is a just bytea splitted on chunks)?
> >> And also PQgetvalue() returns char* rather than unsigned char*.
>
> > Can someone answer this? Are we consistent here?
>
> We're not, particularly, but changing any of this seems likely to
> create more pain than it removes.

OK, thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +