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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to