Yeah, the libpq functions have awfully strange names, and I don't even think you've picked the strangest example. For example, PQftype returns the type OID, and PQfmod returns the type modifier. Why not PQftypemodifier or PQftypemod? Unfortunately, we're kind of stuck with those names at this point, since changing them would break backward compatibility. I suppose we could add more reasonably named synonyms and encourage people to use those instead of the old ones, but I think we'd still end up having to keep the old ones around approximately forever.
Unfortunately this is so.
With respect to PQnfields() vs. PQftablecol(), I think the word "fields" is being used to refer to the columns of the result set, and the word "columns" to refer to the columns of tables on the server.
If so, why does the description of PQnfields() at http://www.postgresql.org/docs/9.0/static/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO says: "Returns the number of columns (fields) in each row of the query result." Furthermore, the description of PQfmod() says: "Returns the type modifier of the column associated with the given column number." So, according the doc, the terms "field" and "column" are interchangeable.
So PQftablecol() is actually trying to tell you the number of the table column where a particular "field" in the results came from. This is sort of a subtle distinction, though, and the fact that "field" is being abbreviated to "f" in some but not all cases doesn't make it any more clear. PQftablecol() is really supposed to mean "field-table-column" - i.e. look up the table column for this field. But the name is definitely less than totally self-documenting.
IMO, it would be better if PQftablecol() was named PQtablefield(), PQfmod() was named PQfieldTypeModifier()() and so on.
IMO, it would be better to only use terms "tuple" and "field" at least in function naming.
