Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable - Mailing list pgsql-hackers
From | Alex Goncharov |
---|---|
Subject | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |
Date | |
Msg-id | E1RCAlg-000E3A-5I@hanssachs.home Whole thread Raw |
In response to | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable (Merlin Moncure <mmoncure@gmail.com>) |
Responses |
Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
|
List | pgsql-hackers |
,--- You/Merlin (Fri, 7 Oct 2011 07:39:57 -0500) ----* | On Thu, Oct 6, 2011 at 5:02 PM, Alex Goncharov | > ,--- Merlin Moncure (Thu, 6 Oct 2011 16:28:56 -0500) ----* | > | hm, good point. not sure how it's useful though. I suppose an | > | application could leverage that for validation purposes, but that's a | > | stretch I think. | > `--------------------------------------------------------* | > | > Thanks for sharing your knowledge of applications. | > | > (Look, I appreciate anybody's reply and readiness to help, but if you | > have a limited expertise in the subject area, why bother replying?) | Well, admittedly, perhaps my response was hastily written. But try | to understand the zen of things around here: often if you | propose/gripe/suggest something, you'll get a challenge back which | is really fishing for more detail. It's not personal. Merlin, I appreciate the spirit of the PostgreSQL technical lists: I am permanently subscribed to PERFORM, and, occasionally, to HACKERS. I regularly unsubscribe from the latter because it quickly overloads me with the flood of messages I have no time even to read, not to say, digest. HACKERS would be one of the most useful technical reads, if it were not so bloody floody. (On GENERAL, take a look at this reply to a question similar to mine: http://archives.postgresql.org/pgsql-general/2005-08/msg01152.php What's the value of this kind of advice?) | By the way, you still haven't explained use cases. As I said yesterday, it is for my client to find various meta data. Also note that I posted the references to common APIs (JDBC and ODBC), where this interface is available, because "nullability" is a natural thing to ask about. You can also find how this kind of functionality is supported, e.g. in Oracle OCI. Plus, now you have seen, from Peter Eisentraut's message that I just replied to, and from the mail archive link I posted a dozen of lines above here, that I am not the first person interested in this kind of functionality in the PostgreSQL land. | You can always talk hypotheticals...'other people do it' is not a | standard for inclusion of a feature (although it can be). I didn't ask anybody to include anything in PostgreSQL; my question, now unambiguously answered (thank you, the list!) was: ,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) ----* | | My understanding is that libpq does not allow one to find if a result | set column is nullable. | | Is this right? | `-------------------------------------------------* Compare this with what you have tried to write about. | I've been coding against libpq for years and years and have never | needed to test for nullability, It's not a serious argument, in my opinion. | so that's where my skepticism comes from. `-------------------------------------------------* But, sincerely, I do appreciate your readiness to help and continuing the conversation this morning. Thank you, -- Alex -- alex-goncharov@comcast.net --
pgsql-hackers by date: