From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | olly(at)lfix(dot)co(dot)uk |
Cc: | "Mace, Richard" <richard(dot)mace(at)Lorien(dot)co(dot)uk>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: |
Date: | 2003-12-18 15:04:53 |
Message-ID: | 19600.1071759893@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> On Thu, 2003-12-18 at 08:40, Mace, Richard wrote:
>> This code works fine for a field that is always populated e.g. name in
>> place of telephone in line 1.
> If a cell is NULL, I think it is undefined in DBI
I'm not much of a DBI user, but one would hope that fetch() represents
null values by storing an undef, rather than failing. Anything else
would indicate utter brain death on the part of the DBI designers.
Richard's example code looks fine to me, but I wonder if it is an exact
copy of his real code. The error message ("Statement has no result to
bind") is pretty specific and it's hard to see how it would come out
from a bind operation on a SELECT statement. I am wondering about
simple typos like applying the bind_columns call to the wrong statement
handle.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mace, Richard | 2003-12-18 15:37:25 | Re: |
Previous Message | Michael Fuhr | 2003-12-18 14:53:21 | Re: |