php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #14698 pg_fetch_array() does not require row param
Submitted: 2001-12-26 01:57 UTC Modified: 2002-01-20 04:00 UTC
From: junk-php at aontic dot com Assigned: yohgaki (profile)
Status: Closed Package: Documentation problem
PHP Version: 4.1.0 OS: Linux
Private report: No CVE-ID: None
 [2001-12-26 01:57 UTC] junk-php at aontic dot com
array pg_fetch_array (resource result, int row [, int result_type])

makes int row appear required, when it is actually optional. 


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-26 02:06 UTC] yohgaki@php.net
I've checked current code. Reporter is right.
I need to check when this has been changed and I think row should be required parameter.  I'll keep this behavior if and only if this was the implemented from the beginning :)
(Current code internally advance row in result structure)

So DO NOT take advantage of this.

 [2001-12-26 02:09 UTC] yohgaki@php.net
Additional comment:
All pg_fetch_* works as reporter mentioned, but
DO NOT take advantage of this.
I may change behavior after I check php3 and php4 CVS log :)

 [2001-12-26 02:13 UTC] junk-php at aontic dot com
Works wonderfully without the row. That's certainly a win convienence wise, especially for folks coming over from mysql where the loop syntax is trivial 

(while $row = fetch())
{}

I'd prefer to see the docs change then the functionality. I'll take a look at the code itself but it is hard to see how this is a performance loss, most users end up keeping a counter anyways.

Why do you prefer making the row required? It seems like a silly added restriction, especially when I bet 80% of the cases where the function is called don't need it. 
 [2001-12-26 02:19 UTC] junk-php at aontic dot com
Implemented 6 months ago by jon (1.112) pgsql.c.
Looks reasonable.

 [2001-12-26 02:26 UTC] yohgaki@php.net
Thanks for checking the change :)
I'm the new module maintainer, so I'm asking previous module maintainers about it. Since MySQL seems it does the same, I'll keep this behavior probably, but it is not a promise yet. ;)

 [2001-12-26 02:31 UTC] junk-php at aontic dot com
Sounds good. I think it would be silly to drop this change.

- It does not appear to impact existing code (patch switches based on argument count) 

- The reason I discovered it because I was annoyed with what I thought the existing behavior was.

Good luck with the new maintainership. 
 [2001-12-27 05:58 UTC] sander@php.net
Status -> assigned
 [2002-01-20 04:00 UTC] yohgaki@php.net
Note added to doc.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 22:01:27 2024 UTC