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.
> D) All others are nullable I think you meant "All others are not nullable." > As I see it, the hardest part of this feature is getting the > information to the client. Ay, there's the rub. > I don't think the reply to a DESCRIBE message is currently > extensible, so we'd probably need to add a new version of the > message. Or a new protocol version. I've been thinking that the next *big* project I look at here might be a new version of the protocol, since I see mentions of protocol limitations preventing things people want with some regularity. We should be keeping a list, and this should be on it. > 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. > 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. > I certainly won't, because I don't really see the benefit. Yeah, it wouldn't be hard to produce a long list of things which would take about the same effort which seem more beneficial to me. It's a matter of whether this is causing someone enough bother to want to devote the resources to changing it. I really think it's that simple. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
