> > 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 know enough about it to agree with you :) > > In the above example, does the database engine assign internally a > > 'nullability' flag? I guess it must do... because how would the > > following be evaluated: > > > > SELECT f1 + f2 AS f INTO TableY FROM TableX WHERE f1 < 30 > > > > Would the column f in the created table be nullable or not? > > > > I guess I need to do some testing unless you know off the top of your > > head? > > I'm not familiar enough with PostgreSQL internals to comment on > what's happening underneath, but I could tell you from experience > what the above query would do. But with a quick test you could > figure it out for yourself :-) Did that once I got access to my postgres server. The f in the created table is nullable in the above example, and also even if f1 and f2 are not nullable themselves, so it looks like that as soon as you start to make a field based on an expression, the 'not null' constraint goes out the window. > The "Incremental results from libpq" thread from a few months ago > might answer your questions: > > http://archives.postgresql.org/pgsql-interfaces/2005-11/msg00010.php Found that eventually. I'd seen the thread earlier but assumed that the word 'incremental' in the subject was to do with auto-incrementing fields. An interesting read. Thanks James