Re: Problem with PQexecPrepared - Mailing list pgsql-interfaces

From David Stanaway
Subject Re: Problem with PQexecPrepared
Date
Msg-id B2F0B3CC-BAA8-11D8-968B-0003930FDAB2@stanaway.net
Whole thread Raw
In response to Re: Problem with PQexecPrepared  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
On Jun 10, 2004, at 12:34 AM, Tom Lane wrote:

> David Stanaway <david@stanaway.net> writes:
>> On Wed, 2004-06-09 at 17:21, Jeroen T. Vermeulen wrote:
>>> Not that it would be a problem here, because the array itself is 
>>> const
>>> and so the function could never write its own pointer into it.  I
>>> think it's one of those rare situations where a cast is justified.
>
>> If the prototype had been for const char** I would not have needed to
>> change anything, the API author I guess is being thorough.
>
> The author was me, and I didn't think I was creating any problems by
> const-ifying the declaration :-(.  Jerome, are you sure this isn't
> a compiler glitch?  I really have a problem with the notion that a
> library routine can over-constify its input declarations...


Hi there,
The library prototype is fine. My GCC is gcc (GCC) 3.3.3 (Debian 
20040422).

Do you have an example of PQexecParams or PQexecPrepared using non text 
parameters?

-- 
David Stanaway <david@stanaway.net>



pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with PQexecPrepared
Next
From: Stephane Raimbault
Date:
Subject: libpq 7.4 and binary cursor