Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 8FD6E4770FD for ; Fri, 8 Nov 2002 10:17:18 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 47056476FE4 for ; Fri, 8 Nov 2002 10:15:21 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id gA8FFDhR005861; Fri, 8 Nov 2002 10:15:13 -0500 (EST) To: Bruce Momjian Cc: Payman , Michael Klatt , pgsql-interfaces@postgresql.org Subject: Re: PQcmdTuples() declaration In-reply-to: <200211080511.gA85B2K11157@candle.pha.pa.us> References: <200211080511.gA85B2K11157@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Fri, 08 Nov 2002 00:11:01 -0500" Date: Fri, 08 Nov 2002 10:15:12 -0500 Message-ID: <5860.1036768512@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/22 X-Sequence-Number: 3270 Bruce Momjian 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. regards, tom lane