PostgreSQL boolean true becomes string "t"
PostgreSQL boolean false becomes string "f"
This is ambiguous, and leads to code duplication. I wonder why aren't the types correctly typed when fetching values. We could at least have an optional parameter to enable that.
pg_fetch_object
(PHP 4, PHP 5)
pg_fetch_object — Lit une ligne de résultat PostgreSQL dans un objet
Description
pg_fetch_object() retourne un objet ainsi que ses propriétés qui correspond aux noms des champs de la ligne. La fonction peut optionnellement instancier un objet d'une classe spécifique et passer les paramètres au constructeur de cette classe.
Note: Cette fonction définit les champs NULL à la valeur PHP NULL.
Du point de vue vitesse, la fonction est identique à pg_fetch_array() et est presque aussi rapide que pg_fetch_row() (la différence est insignifiante).
Liste de paramètres
- result
-
Ressource de résultat de requête PostgreSQL, retournée par pg_query(), pg_query_params() ou pg_execute() (entre autres).
- row
-
Numéro de la ligne à récupérer. Les lignes sont numérotées en commençant à 0. Si l'argument est omis ou s'il vaut NULL, la ligne suivante est récupérée.
- result_type
-
Ignoré et obsolète.
- class_name
-
Le nom de la classe à instancier, fixe les propriétés de celles-ci et ses valeurs de retour. Si rien n'est spécifié, un objet de style stdClass est retourné.
- params
-
Paramètre optionnel de type array pour passer des arguments au constructeur de la classe class_name.
Valeurs de retour
Un objet de type object avec les attributs pour chaque champ dans le jeu de résultats. Les valeurs NULL de la base de données sont retournées NULL.
FALSE est retournée si row excède le nombre de lignes dans le jeu de résultats, n'a plus de ligne disponible ou tout autre erreur.
Historique
| Version | Description |
|---|---|
| 5.0.0 | class_name et params ont été ajoutés. L'ancien format du paramètre result_type existe toujours pour des raisons de compatibilité avec les versions antérieures. |
| 4.3.0 | result_type ne vaut plus PGSQL_BOTH par défaut, mais PGSQL_ASSOC, depuis que l'index numérique est devenu illégal. |
| 4.1.0 | Le paramètre row devient optionnel. |
Exemples
Exemple #1 Exemple avec pg_fetch_object()
<?php
$database = 'store';
$db_conn = pg_connect("host=localhost port=5432 dbname=$database");
if (!$db_conn) {
echo "La connexion a la base $database a échouée\n";
exit;
}
$qu = pg_query($db_conn, "SELECT * FROM livres ORDER BY auteur");
while ($data = pg_fetch_object($qu)) {
echo $data->auteur . " (";
echo $data->annee . "): ";
echo $data->titre . "<br />";
}
pg_free_result($qu);
pg_close($db_conn);
?>
Voir aussi
- pg_query() - Exécute une requête PostgreSQL
- pg_fetch_array() - Lit une ligne de résultat PostgreSQL dans un tableau
- pg_fetch_assoc() - Lit une ligne de résultat PostgreSQL sous forme de tableau associatif
- pg_fetch_row() - Lit une ligne dans un tableau
- pg_fetch_result() - Retourne les valeurs d'un résultat
I noticed that many people use FOR loops to extract query data. This is the method I use to extract data.
<?php
@$members = pg_query($db_conn, 'SELECT id,name FROM boards.members ORDER BY name;');
if ($members AND pg_num_rows($members)) {
while ($member = pg_fetch_object($members)) {
echo $member->name.' ('.$member->id.')';
}
}
?>
If an error occurs (or nothing is returned) in the above code nothing will output. An ELSE clause can be added to the IF to handle query errors (or nothing being returned). Or a seperate check can be performed for the event that nothing is returned by using an ELSEIF clause.
I like this method because it doesn't use any temporary counter variables.
If you're wanting to use objects for your results, but are put off because you can't seem to apply a function to each field of the result (like stripslashes for example), try this code:
<?php
// Code to connect, do query etc etc...
$row = pg_fetch_object($result);
$vars = get_object_vars($row);
foreach ( $vars as $key => $var )
{
$row->{$key} = stripslashes($var);
}
?>
Something I have learned to use:
$result=$pg_query (...);
$num = pg_numrows($result);
for($count=0;$count < $num && $data=pg_fetch_object($result,$count);$count++)
{
printf("<tr>\n");
printf(" <td>%s</td>\n",$data->foo);
printf(" <td>%s</td>\n",$data->bar);
printf("</tr>\n");
}
When you retrieve the contents of a "timestamp with timezone" field, this will set the environment's timezone variables. Therefore, this is dangerous:
$s=$row->mydatefield;
$unixtimestamp=postgresqltimestamp2unix($s);
echo date("Y-m-d H:i:s",$unixtimestamp);
Here, postgresqltimestamp2unix is a function that converts the postgresql timestamp to Unix. The retrieval of the field data in the first line of the example above will influence the timezone used in date() in the third line.
This isn't all that useful. If you do, for example, foreach($row as $field) then you still get every value twice!
You can do something like this, though:
foreach ($line as $key => $cell){
if (! is_numeric($key)){
echo "<td>$key $cell</td>";
}
}
is is_numeric strict enough?
The result_type arg is either invalid or incorrectly documented, since the "result_type is optional..." paragraph is copied verbatim from pg_fetch_array, and the PGSQL_NUM option is in conflict with the preceding paragraph's, "you can only access the data by the field names, and not by their
offsets."
