Re: PQcmdTuples() declaration

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Payman <payman(at)Club-Internet(dot)fr>, Michael Klatt <mdklatt(at)ou(dot)edu>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: PQcmdTuples() declaration
Date: 2002-11-08 15:55:11
Message-ID: 200211081555.gA8FtBa03406@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The issue with PQcmdTuples() and PQcmdStatus() are that they return
> > *result structure member pointers. The patch makes the *result a const,
> > then we have to return the values as const's. The code compiled OK, so
> > I assume that is fine. How does that sound to others, or should we keep
> > the result non-const?
>
> Adding a const to the result type will break client applications that
> aren't expecting it. I don't think we can get away with that.
>
> We could still declare the input type as const if we were willing to
> cast away const inside the functions, but that seems pretty ugly.

Yep, seems pretty ugly to me too. Why bother calling it a const if we
are going to cast it away.

I have updated the docs for 7.3 and CVS to match the non-const code.
Let's see if this issue comes up again.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Llew 2002-11-11 14:54:19 Binary cursors and arrays
Previous Message Tom Lane 2002-11-08 15:15:12 Re: PQcmdTuples() declaration