On Oct6, 2011, at 22:38 , Merlin Moncure wrote:
> On Thu, Oct 6, 2011 at 3:22 PM, Alex Goncharov
> <alex-goncharov@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