Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable

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

In response to

Browse pgsql-hackers by date

  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