Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable

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