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

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