ID:               28994
 Updated by:       [EMAIL PROTECTED]
 Reported By:      bas at vanklinkenbergsoftware dot nl
 Status:           Closed
 Bug Type:         Documentation problem
 Operating System: N/A
 PHP Version:      4.3.7
 New Comment:

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.




Previous Comments:
------------------------------------------------------------------------

[2004-07-04 04:41:06] cysgwr_eyri at yahoo dot co dot uk

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. ;)

------------------------------------------------------------------------

[2004-07-04 04:22:18] bas at vanklinkenbergsoftware dot nl

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.

------------------------------------------------------------------------

[2004-07-04 03:14:59] cysgwr_eryri at yahoo dot co dot uk

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

------------------------------------------------------------------------

[2004-07-03 03:30:24] bas at vanklinkenbergsoftware dot nl

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

------------------------------------------------------------------------

[2004-07-02 23:17:01] [EMAIL PROTECTED]

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

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/28994

-- 
Edit this bug report at http://bugs.php.net/?id=28994&edit=1

Reply via email to