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@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------