>
> 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
