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

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Alex Goncharov <alex-goncharov(at)comcast(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Date: 2011-10-08 21:07:01
Message-ID: CAFNqd5UCW6aX3CPMEDQUJbg6Ca=mzbe+fGyKXbqEZnjPrYpnPg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'll point to rather different reasoning...

Libpq is not returning tables, or relations, for that matter, but rather the
results of queries.

It is reasonable to expect to know which attributes of a table are or are
not nullable, and that is commonly available as an attribute of
pg_attribute, however...

General purpose queries are nowhere near so predetermined. Indeed, whether
a column is nullable may not be at all visible, as the value of a column may
be computed by a function and thereby be quite opaque to static analysis.

That makes me think that guessing which attributes of a query may be null
seems like a pretty futile exercise. At first blush, we could simplify to
PQnullable() always returning true, but that's not terribly revealing.
However, often, there mayn't be a much better solution that isn't really
tough to implement.

I'd not be keen on people putting much effort into futile exercises ; better
to work on things that are "less futile."

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2011-10-09 00:14:21 Re: Range Types - typo + NULL string constructor
Previous Message Robert Haas 2011-10-08 20:08:43 Re: index-only scans