On Oct6, 2011, at 22:38 , Merlin Moncure wrote: > On Thu, Oct 6, 2011 at 3:22 PM, Alex Goncharov > <alex-goncha...@comcast.net> wrote: >> ,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) ----* >> | My understanding is that libpq does not allow one to find if a result >> | set column is nullable.
>> ,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) ----* >> | why aren't you using PQgetisnull()? >> >> This function is not about the nullability of a column but rather >> about the value in a result set cell: >> >> PQgetisnull: Tests a field for a null value. >> >> int PQgetisnull(const PGresult *res, int row_number, int column_number); >> >> Notice the 'row_number'. > > right -- get it. well, your question is doesn't make sense then -- > any column can be transformed in ad hoc query, so it only makes sense > to test individual values post query.. btw, if you don't like > querying system catalogs, check out information_schema.columns. Sure, but there are still a lot of cases where the database could deduce (quite easily) that a result column cannot be null. Other databases do that - for example, I believe to remember that Microsoft SQL Server preserves NOT NULL constraints if you do CREATE TABLE bar AS SELECT * from foo; So the question makes perfect sense, and the answer is: No, postgres currently doesn't support that, i.e. doesn't deduce the nullability of result columns, not even in the simplest cases. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers