Thread: ColumnName and ColumnNumber in libpq (C interface)
I think this behaviour is not fine:
I create a table with
CREATE TABLE foo ("Bar" VARCHAR(1));
I thougth running this helloworldish C program:
#include <stdio.h>
#include <libpq-fe.h>
int main(int argc,char **argv)
{ PGconn * conn = PQconnectdb("dbname=pruebas"); PGresult * res = PQexec(conn,"SELECT * from foo");
printf("%s\n",PQfname(res,0)); printf("%d\n",PQfnumber(res,"Bar")); PQfinish(conn);
}
should print
Bar
0
but stdout shows
Bar
-1
What is happening? Any ideas? Is this a bug, a feature or something I'm missing?
--
-----------------------
Alberto Cabello Sánchez
alberto@unex.es
Servicio de Informática
924 289 351
-----------------------
>
> I think this behaviour is not fine:
> I create a table with
> CREATE TABLE foo ("Bar" VARCHAR(1));
>
> I thougth running this helloworldish C program:
>
> #include <stdio.h>
> #include <libpq-fe.h>
> =20
> int main(int argc,char **argv)
> {
> PGconn * conn =3D PQconnectdb("dbname=3Dpruebas");
> PGresult * res =3D PQexec(conn,"SELECT * from foo");
> printf("%s\n",PQfname(res,0));
> printf("%d\n",PQfnumber(res,"Bar"));
> PQfinish(conn);
> }
>
> should print=20
>
> Bar
> 0
>
> but stdout shows
>
> Bar
> -1
>
> What is happening? Any ideas? Is this a bug, a feature or something
I'm m=
> issing?
>
It's something you're missing:
All names are folded to lowercase, except enclosed in double quotes. So
printf("%d\n",PQfnumber(res,"\"Bar\""));
gives you the right result.
Regards, Christoph
Christoph Haller <ch@rodos.fzk.de> writes:
>> I thougth running this helloworldish C program:
>> should print
>> Bar
>> 0
>>
>> but stdout shows
>> Bar
>> -1
>>
> All names are folded to lowercase, except enclosed in double quotes. So
> printf("%d\n",PQfnumber(res,"\"Bar\""));
> gives you the right result.
I wonder whether this behavior is appropriate for PQfnumber, though.
It's never been documented ... and certainly should be if we decide
we should keep it. Comments?
regards, tom lane
>
> Christoph Haller <ch@rodos.fzk.de> writes:
> >> I thougth running this helloworldish C program:
> >> should print
> >> Bar
> >> 0
> >>
> >> but stdout shows
> >> Bar
> >> -1
> >>
>
> > All names are folded to lowercase, except enclosed in double quotes.
So
> > printf("%d\n",PQfnumber(res,"\"Bar\""));
> > gives you the right result.
>
> I wonder whether this behavior is appropriate for PQfnumber, though.
> It's never been documented ... and certainly should be if we decide
> we should keep it. Comments?
>
> regards, tom lane
>
I'd say it should be left as it is, and documented of course.
I can see a possible ambiguity, if someone is queer enough to
define columns like "bar", "Bar", "BAR", etc. within the same table.
Regards, Christoph
On Mon, Sep 15, 2003 at 10:48:47AM -0400, Tom Lane wrote: > > I wonder whether this behavior is appropriate for PQfnumber, though. > It's never been documented ... and certainly should be if we decide > we should keep it. Comments? > I think PQfnumber(res,PQfname(res,0))==-1 should_never_happen (c) with a valid PGresult * res. Maybe PQfname(res,0) should be "\"Bar\"", not "Bar". Have a nice coding. -- ----------------------- Alberto Cabello Sánchez alberto@unex.es Servicio de Informática 924 289 351 -----------------------
Alberto Cabello Sanchez <alberto@unex.es> writes:
> On Mon, Sep 15, 2003 at 10:48:47AM -0400, Tom Lane wrote:
>> I wonder whether this behavior is appropriate for PQfnumber, though.
>> It's never been documented ... and certainly should be if we decide
>> we should keep it. Comments?
> I think PQfnumber(res,PQfname(res,0))==-1 should_never_happen (c) with a
> valid PGresult * res.
> Maybe PQfname(res,0) should be "\"Bar\"", not "Bar".
I don't really want to change PQfname; that would probably break more
apps than changing PQfnumber.
We could achieve the property you suggest if we forgot about
case-insensitive matching and dequoting, and simply made PQfnumber check
for an exact match.
Or we could try some combination behavior (say, try exact match, then
if no luck apply the dequote/downcase logic). This might offer better
backwards compatibility, but the more complex the behavior, the more
potential for surprising corner cases ...
regards, tom lane
On Tue, Sep 16, 2003 at 09:46:26AM -0400, Tom Lane wrote: > I don't really want to change PQfname; that would probably break more > apps than changing PQfnumber. > > We could achieve the property you suggest if we forgot about > case-insensitive matching and dequoting, and simply made PQfnumber check > for an exact match. ...but this is also app breaker. > > Or we could try some combination behavior (say, try exact match, then > if no luck apply the dequote/downcase logic). This might offer better > backwards compatibility, but the more complex the behavior, the more > potential for surprising corner cases ... > What about a PQfrealname function (actually, a macro) which returns quoted string? I hope this suggestion is not too stupid. -- ----------------------- Alberto Cabello Sánchez alberto@unex.es Servicio de Informática 924 289 351 -----------------------