There was a discussion on -interfaces that might need more consideration.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.
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 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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
