On Wed, Feb 01, 2006 at 09:47:12AM +1100, James Harper wrote:
> Now, given the current where clause, the client isn't going to see any
> NULL values, but a change in the where clause might suddenly make the
> calculated f field nullable. Maybe this doesn't matter and the client
> application should
> On Tue, Jan 31, 2006 at 10:23:54PM +1100, James Harper wrote:
> > For the libpq interface:
> >
> > I need to be able to know if a column in a result from a query is
> > nullable or not. From reading the documentation it seems that I can
> > obtain the following information:
> > . scan all the row
>
> Even if such a query did return a "nullable" flag, plenty of other
> metadata would be absent that might be just as interesting from a
> schema-viewing standpoint (CHECK, PRIMARY KEY, etc.). A better way
> to view the schema is to query the system catalogs or the Information
> Schema.
I now
On Wed, Feb 01, 2006 at 09:47:12AM +1100, James Harper wrote:
> > Be careful what you infer from such a scan: not finding any NULLs
> > doesn't necessarily mean a column isn't nullable, it just means the
> > result set didn't contain any NULLs.
>
> I understand that limitation, but haven't figured
On Tue, Jan 31, 2006 at 10:23:54PM +1100, James Harper wrote:
> For the libpq interface:
>
> I need to be able to know if a column in a result from a query is
> nullable or not. From reading the documentation it seems that I can
> obtain the following information:
> . scan all the rows in the resu
For the libpq interface:
I need to be able to know if a column in a result from a query is
nullable or not. From reading the documentation it seems that I can
obtain the following information:
. scan all the rows in the result and see if there exists a null value
for each column...
. backtrack the
