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

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 --

In response to

Responses

Browse pgsql-hackers by date

  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