X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id B318AD1B53A for ; Sun, 5 Oct 2003 18:03:07 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 78997-10 for ; Sun, 5 Oct 2003 15:02:22 -0300 (ADT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id A9864D1B53C for ; Sun, 5 Oct 2003 15:02:20 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.10/8.12.10) with ESMTP id h95I2Jhn006599; Sun, 5 Oct 2003 14:02:19 -0400 (EDT) To: Andreas Pflug Cc: Peter Eisentraut , PostgreSQL Development , pgsql-interfaces@postgresql.org Subject: Re: [HACKERS] PQfnumber and quoted identifiers In-reply-to: <3F80583E.3030606@pse-consulting.de> References: <3F803498.8080400@pse-consulting.de> <1258.1065373207@sss.pgh.pa.us> <3F80583E.3030606@pse-consulting.de> Comments: In-reply-to Andreas Pflug message dated "Sun, 05 Oct 2003 19:43:26 +0200" Date: Sun, 05 Oct 2003 14:02:18 -0400 Message-ID: <6598.1065376938@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/10 X-Sequence-Number: 4499 Andreas Pflug writes: > If you change it, please give me a chance to code it version-aware so > quoting/non-quoting can be performed dependent on libpq in use. If you want a run-time test, the most reliable way would be to directly test what PQfnumber does --- for instance, make a query known to contain the column name "foo", and see what PQfnumber(res, "\"foo\"") returns. I'm not sure there is any other solution, since we can't retroactively install a version identifier in old libpq releases. For a compile-time test, you could perhaps look to see if PG_DIAG_SQLSTATE or one of the other new macros in postgres_ext.h is defined. Not sure you really want a compile-time test though; it'd break very easily if you get linked against some other version of the library. As for the more general question of whether to offer libpq version identification going forward, I have no strong opinion on whether it's really useful or not. If it's wanted, I'm tempted to suggest that PQparameterStatus() could be extended to recognize "libpq_version" paralleling "server_version". Not sure about a clean way to expose the version at compile time. regards, tom lane