From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Alex Goncharov <alex-goncharov(at)comcast(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |
Date: | 2011-10-06 21:28:56 |
Message-ID: | CAHyXU0w7JSfFok7wudD+3heiEbMMHXjeaGHGEeY95-SNRhm+EA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 6, 2011 at 4:16 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> 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.
hm, good point. not sure how it's useful though. I suppose an
application could leverage that for validation purposes, but that's a
stretch I think.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-10-06 21:46:48 | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) |
Previous Message | Florian Pflug | 2011-10-06 21:16:53 | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |