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
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 |