From: | Alex Goncharov <alex-goncharov(at)comcast(dot)net> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |
Date: | 2011-10-07 13:47:16 |
Message-ID: | E1RCAlg-000E3A-5I@hanssachs.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)comcast(dot)net --
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-07 13:53:53 | Re: alter table only ... drop constraint broken in HEAD |
Previous Message | Alex Goncharov | 2011-10-07 13:13:54 | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |