Sam Mason <s...@samason.me.uk> wrote: > On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote: >> Sam Mason <s...@samason.me.uk> wrote: >> > CREATE VIEW v (c) AS >> > SELECT NULL; >> > >> > PG allows it, but the resulting view seems somewhat unusable. >> >> I'm not sure whether the only place the standard doesn't require a >> cast is on assignment, but this is one place that the standard >> clearly does require a cast, and I'm all for that. > > I'm probably missing something obvious again, but where does it say > that? Bear in mind that my simple NULL could be an arbitrarily > complex expression, I've just chosen a simple NULL for pedagogic > reasons. > > I can only see a requirement that the chosen type must be > compatible. That seems to leave it open to arbitrarily choosing any > type in this case. I'll look. On reflection, I based that statement on the fact that our SQL parser requires it, and it was largely created by scanning in the SQL syntax rules, using OCR on the image, and sed to format them for ANTLR. That doesn't guarantee that we didn't add that particular requirement for the sake of our own sanity some time later. I doubt I can get to looking through the standard for it today, though. By the way, the case of a bare NULL literal is potentially very different from a complex expression which might resolve to NULL. The latter would generally have some result type which could be determined even in tha absence of an actual value. For example, a null-capable column clearly has a type which can be determined. -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
