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:

Previous
From: Alex Goncharov
Date:
Subject: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Next
From: Robert Haas
Date:
Subject: Re: alter table only ... drop constraint broken in HEAD