On Oct9, 2011, at 14:20 , Kevin Grittner wrote: > Florian Pflug wrote: > >> Coming up with a reasonable algorithm isn't *that* hard. > > Agreed. Our shop has used a home-grown framework for over a decade > where we parse queries using ANTLR ( http://www.antlr.org/ ) and we > tracked this trough all expressions. There really weren't that many > situations where we had to punt.
Sounds cool. What was your use-case for doing that? >> D) All others are nullable > > I think you meant "All others are not nullable." Ups, yeah, right, that was supposed to read *non*-nullable. >> That might be a rather tough sell, as least as long as there's >> isn't a clear use-case for this. Which, unfortunately, nobody has >> provided so far. > > Yeah. It would be nice to see at least one use case. The only > comment I recall is a vague suggestion that that people might want to > select data from a table and infer table attributes from the result > set metadata. That seems marginal. Well, there is one other, namely SQL standards compliance. It does mandate that "CREATE TABLE ... AS SELECT" creates NOT NULL constraints on non-nullable columns I think (I didn't re-check, though). I'm not sure I see the value in that either, but, hey, standards compliance ought to be a value it in itself, right? >> the question is simply whether one values to feature enough to put >> in the word. > > ... or fund the work. There are people for hire in the community. And that was, of course, supposed to read "put in the *work*". Alas, just putting in the *word* is probably not going to be enough ;-) 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