,--- You/Bruce (Thu, 6 Oct 2011 19:09:16 -0400 (EDT)) ----*
| > (Look, I appreciate anybody's reply and readiness to help, but if you
| > have a limited expertise in the subject area, why bother replying?)
| FYI, I see 867 Postgres posts mentioning Merlin Moncure in the past
| year:

I watch most of the PostgreSQL technical lists all the time and know
who is who.

I didn't mean to be disparaging (and said, "Look, I appreciate
anybody's reply and readiness to help").

But really, before replying, one should think about the posted
question, and resist opinionating on the topics little thought about
and worked with.

To this:

,--- Merlin Moncure (Thu, 6 Oct 2011 15:16:18 -0500) ----*
| why aren't you using PQgetisnull()?

I replied politely:

,--- I/Alex (Thu, 06 Oct 2011 16:22:28 -0400) ----*
| This function is not about the nullability of a column but rather
| about the value in a result set cell:
|   PQgetisnull: Tests a field for a null value. 
|      int PQgetisnull(const PGresult *res, int row_number, int column_number);
| Notice the 'row_number'.     

To this:

,--- Merlin Moncure (Thu, 6 Oct 2011 15:38:59 -0500) ----*
| right -- get it.  well, your question is doesn't make sense then --
| btw, if you don't like querying system catalogs, check out
| information_schema.columns.

it was harder; still, I stayed in the technical area:

,--- I/Alex (Thu, 06 Oct 2011 18:02:41 -0400) ----*
| What?..
| * It makes complete logical sense to ask a question if a result set
|   column may ever have a NULL cell.
| * It can be done for a table using pg_attribute.attnotnull.
| * It can be done, at the C API level, in a wide variety of other
|   databases, including the two most often mentioned in this audience:
|   Oracle (through and OCI call) and MySQL (at least through ODBC.)

To this:

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

it was plain hard -- the expressed opinion didn't relate to the
original question, and was, besides, quite unfounded.

,--- Andrew Dunstan (Thu, 06 Oct 2011 18:30:44 -0400) ----*
| People are trying to help you. Please be a little less sensitive. 
| Sneering at Merlin is not likely to win you friends. 

I know.

I wouldn't have been sensitive about an opinion on a side topic ("not
sure how it's useful though") (did anybody asked about that?), had
Merlin also offered sound and relevant technical points.  He hadn't.

On the technical point now:

It's clear enough for me at this point, that I had not overlooked
anything in libpq and it doesn't support finding a result set column
nullability (no hypothetical PQfisnullable function or a hidden way to
use other PQf* functions for this purpose.)

I will resort to the ugly method I outlined in my previous message,

,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) ----*
|   (1)   Oid PQftable(const PGresult *res, int column_number);
|   (2)   int PQftablecol(const PGresult *res, int column_number);
|   (3)   a SQL query of pg_attribute,attnotnull

Thanks everybody who replied!

P.S. And on the odd chance that somebody thinks that this
     functionality would be possible and helpful to add to libpq, and
     the problem is in the lack of human resources: I would be more
     then happy to dig into some PostgreSQL (the product) development
     under somebody's coaching, to start with.  This topic or other.
     I just wouldn't know where to start myself.

-- Alex -- alex-goncha...@comcast.net --

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to