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