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 result and see if there exists a null value > for each column... 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. > . backtrack the column to the source table (assuming a non-calculated > field) and check the nullable status there > > Neither of the above is particularly cheap to do... If you know the table and column names then checking which columns have a NOT NULL constraint is a simple query against pg_attribute. > Which leads me to my next question... If I executed a select against a > table with a million rows, and the query returned all of the rows, what > happens? Are all the rows read into memory on the client before > returning the result? Or are rows only fetched from the server as > required? libpq fetches all rows before returning any to the client; if you want to fetch rows in smaller chunks then use a cursor. The developers' TODO list has an item to address that problem: * Allow statement results to be automatically batched to the client http://www.postgresql.org/docs/faqs.TODO.html -- Michael Fuhr
