Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
| От | Christopher Browne |
|---|---|
| Тема | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable |
| Дата | |
| Msg-id | CAFNqd5UCW6aX3CPMEDQUJbg6Ca=mzbe+fGyKXbqEZnjPrYpnPg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable (Alex Goncharov <alex-goncharov@comcast.net>) |
| Ответы |
Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
|
| Список | pgsql-hackers |
<p>I'll point to rather different reasoning...<p>Libpq is not returning tables, or relations, for that matter, but ratherthe results of queries.<p>It is reasonable to expect to know which attributes of a table are or are not nullable, andthat is commonly available as an attribute of pg_attribute, however...<p>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 bya function and thereby be quite opaque to static analysis.<p>That makes me think that guessing which attributes of a querymay be null seems like a pretty futile exercise. At first blush, we could simplify to PQnullable() always returningtrue, but that's not terribly revealing. However, often, there mayn't be a much better solution that isn't reallytough to implement.<p>I'd not be keen on people putting much effort into futile exercises ; better to work on thingsthat are "less futile."
В списке pgsql-hackers по дате отправления: