| 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: | Whole Thread | Raw Message | 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 |