What I can see in the sources is that the proto is:

int pg_field_prtlen(resource result, [int row,] mixed field_name_or_number


Row is optional and the last parameter can be either a string or an integer. If it's passed as string, it is recongnised as the field name, otherwise as the field number.

I've never used PostgreSQL, so can you or somebody confirm if the function is behaving as I've stated, please??

Thanks,
Nuno

All right, some more investigation shows me that when using lower case column names, all works well. When using mixed case column names, using a string as the third argument generates the 'Bad Column Offset' error. See code snippet below. Note that fieldnames are correctly retrieved with pg_field_name().

    $db_conn = pg_connect("host = localhost port = 5432 dbname = test user = test password = test");
    $result = pg_query($db_conn, 'SELECT * FROM test');
    echo "table column index 0, has a lower case name, works fine:<br>\n";
    $fieldname = pg_field_name($result, 0);
    echo "fieldname: $fieldname <br>\n";
    $fieldlength = pg_field_prtlen($result, 0, 0);
    echo "fieldlength: $fieldlength <br>\n";
    $fieldlength2 = pg_field_prtlen($result, 0, $fieldname);
    echo "fieldlength: $fieldlength2 <br>\n";

    echo '<br>table column index 1, has a mixed case name, generates e_notice and empty fieldlength:<br>\n';
    $fieldname = pg_field_name($result, 1);
    echo "fieldname: $fieldname <br>\n";
    $fieldlength3 = pg_field_prtlen($result, 0, 1);
    echo "fieldlength: $fieldlength3 <br>\n";
    $fieldlength4 = pg_field_prtlen($result, 0, $fieldname);
    echo "fieldlength: $fieldlength4 <br>\n";

You can test the code above at this url:
http://212.61.21.72/test/pg_field_prtlen_test.php

The database table used in the above code looks like this:
==============
Welcome to psql 7.3.4-RH, the PostgreSQL interactive terminal.

You are now connected to database test as user test.
test=> select * from test;
 first_column | Second_Column
--------------+----------------
            1 | some text
            2 | some more text
(2 rows)

test=>
============

Appearantly it looks like there are two problems: the documentation problem, where the possibility to pass an int as the third argument is not documented, and the error that occurs when using mixed case column names. Should I file the latter as a separate bug?

Regards,
Bas

You can enter either a column name, or a column offset as the last argument, you're supposed to stick to names for portability reasons, which is probably why this isn't documented.

The problem you're having is due to your code. Postgres automatically folds all identifiers (e.g. table / column names) to *lower-case* values. To get it to recognize upper-case values, you must always wrap the identifier in quotes. Presumably, you must have had to use quotes in your CREATE TABLE statement just to have an upper-case column name to begin with.

Your problem comes from the fact that you are initializing $fieldname directly with the return value of a pg_field_name() function call. This is correctly returning the name to you in upper-case form, but when you pass it back to pg_field_prtlen(), it is not quoted in the statement, so postgres is considering it lower-case as far as the query is concerned. If you add the following statement:

$fieldname = '"' . $fieldname . '"';

immediately after the second call to pg_field_name(), you'll see what I mean.

See the manual for more information:
http://www.postgresql.org/docs/7.4/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS

ok, thanks for the input. I expected PHP to take care of the quoting of mixed case column names for me, but understand now that I have to take care of that myself.
I'll just leave a note in the user comments in the online documentation stating that you can also use column numbers with pg_field_prtlen and close this bug report.

No worries.

It's a tricky one. People get used to the fact that SQL is case-insensitive, and use that to make their sentence semantics clearer. If PHP automatically quoted the variable, it could break applications which relied on postgres' default behaviour.

In the C source the functions aren't as separate as they look at the PHP level. Many of the PHP functions go through the same C function which then determines behaviour based on input. This is another reason you can't really auto-quote the vars: It may make sense for certain functions (e.g. pg_field_prtlen()) but not for some of the others going through the same C function interface. This, again, is more to do with the postgres library than PHP itself.

I only know this myself because postgres has mashed me up a few times too. ;)

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.