Skip site navigation (1) Skip section navigation (2)

Re: Problem with PQexecPrepared

From: David Stanaway <david(at)stanaway(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Problem with PQexecPrepared
Date: 2004-06-10 06:37:52
Message-ID: B2F0B3CC-BAA8-11D8-968B-0003930FDAB2@stanaway.net (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Jun 10, 2004, at 12:34 AM, Tom Lane wrote:

> David Stanaway <david(at)stanaway(dot)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(at)stanaway(dot)net>


In response to

pgsql-interfaces by date

Next:From: Stephane RaimbaultDate: 2004-06-10 14:30:27
Subject: libpq 7.4 and binary cursor
Previous:From: Tom LaneDate: 2004-06-10 05:34:12
Subject: Re: Problem with PQexecPrepared

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group