On 24/07/2008 10:41, admin wrote:
I ended up using pg_prepare() and pg_execute() as pg_query() alone just
didn't seem to work. But SELECT statements seemed to be cached or
persistent in some way, such that they "lived" beyond the life of the
PHP script. Is there something I need to know about persistent behaviour
in PG that doesn't exist in MySQL?
That's not something I've ever encountered, and I've done a good bit of
PHP+PG at this stage. Can you show us an example? Also, how are you
connecting? - are you simply doing pg_connect(....) to connect directly,
or is there anything else in the middle - maybe a connection pooler of
some kind?
Another problem was that no matter how many times I checked and
re-checked code, or which pg_fetch_* function I used, copying an array
member and trying to use it later just would not work, eg
while ($row = pg_fetch_array($query)) {
$content = $row[0]
}
echo $content;
$content was always 'undeclared'.
Again, this ought to be fine as you've shown it....can you show us the
SELECT statement and other information?
Some examples I found used PHP's pg_num_rows() function to count the
rows in a result, then iterated through them with a "for" loop ... is
this required behaviour (PHP docs don't appear to discuss this)?
No real need - I generally use the idiom you have above -
$rs = pg_query($sql_string);
while ($row = pg_fetch_assoc($rs)
{
$value = $row['col1'];
// etc....
}
Another weird one was that this statement always failed:
$name = "file.php";
SELECT fld_content FROM tbl_page WHERE fld_name='$name'
That's because you need to use double-inverted-commas for string
interpolation:
...WHERE fld_name = "$name"
Ray.
------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@xxxxxx
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------
