Message-ID: <3F803498.8080400@pse-consulting.de>
Date: Sun, 05 Oct 2003 17:11:20 +0200
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: PQfnumber and quoted identifiers
References: <Pine.LNX.4.44.0310051632370.2745-100000@peter.localdomain>
In-Reply-To: <Pine.LNX.4.44.0310051632370.2745-100000@peter.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

>There was a discussion on -interfaces that might need more consideration.
>
>http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
>
>
>Apparently, it has so far been an undocumented feature of libpq's function
>PGfnumber (return column number from column name) that the column name
>needs to be double-quoted if it contains upper-case letters.  That, is you
>need to write
>
>PQfnumber(res, "\"Bar\"")
>
>I think this is completely bizarre and pointless.  This is a C interface
>and not SQL.  Other libpq functions that accept names of SQL objects don't
>do this.  Also, PQfname and PQfnumber ought to be inverses.
>
>Since this behavior was undocumented and no one had noticed it in the last
>10 years, I think we can away with removing it.
>  
>
I don't agree; you'll certainly break all libpq apps that contact 
databases with columns that have uppercase or special chars, and the 
failure might be very subtle because in most cases you wouldn't expect 
that this function call fails after you successfully created a rowset. 
There's no way how an app could determine which flavor of escaping is 
necessary for PQfnumber.

I completely agree that PQfnumber should have been designed C-like right 
from the start, at least this is how C programmers would expect it. I 
had to learn the hard way that doesn't. While I don't have a problem 
with either version, IMHO now it's far too late to change the behaviour. 
As an alternative, a new function could be invented.

BTW, I'd suggest that libpq gets a PQversion() function or macro, so 
that slight changes in behaviour could be taken  in account on the app 
side if necessary.

Regards,
Andreas