On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane wrote:
> (Of course, I'm not for the feature w.r.t. SQL either. But breaking data
> compatibility is just adding an entire new dimension of trouble.
>
Another dimension of the trouble is breaking the operation of the
tools that parse SQL statements for
,--- You/Peter (Tue, 10 Jan 2012 19:13:42 +0200) *
| On tis, 2011-12-13 at 07:55 -0500, Alex Goncharov wrote:
| > char *PQcmdStatus(PGresult *res);
| > char *PQcmdTuples(PGresult *res);
| >
| > Unreasonable:
| >
| > a. What, these two can modify 'res' I pass
,--- I/Alex (Tue, 13 Dec 2011 07:55:45 -0500) *
| If the above change causes a warning in a client code, so much the
| better: the client code is doing something unreasonable like the "*s"
| assignment in my example above.
,--- Robert Haas (Tue, 13 Dec 2011 10:51:54 -0500) *
| Or they just
Compare:
int PQntuples(const PGresult *res)
Reasonable: doesn't modify 'res'.
With:
char *PQcmdStatus(PGresult *res);
char *PQcmdTuples(PGresult *res);
Unreasonable:
a. What, these two can modify 'res' I pass in?..
b. Oh, yes, because they return 'char *' pointing to
'res->cmd
Thank you all who replied!
-- Alex -- alex-goncha...@comcast.net --
/*
* They're only trying to make me LOOK paranoid!
*/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks...
,--- You/Tom (Sun, 09 Oct 2011 22:29:19 -0400) *
| Well, HP hasn't exactly been forthcoming with support on their own end,
| but we do have an HPUX 11.31 IA64 machine in the buildfarm,
Should I read the above as:
1. The PostgreSQL server will build on HPUX 11.31 IA64.
2. The s
[ Thanks all for the very productive discussion in the thread
"libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable"
which I originated. Very useful. Now on something different. ]
About two years ago, I had to research some PostgreSQL failures on
HP-UX on a lame PA-RISC box. Lookin
The obvious typos:
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2, if I didn't see the 'create's.
| Now, for this statement, I can easily identify non-nullable col
,--- 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 valid
,--- Peter Eisentraut (Fri, 07 Oct 2011 11:14:09 +0300) *
| On tor, 2011-10-06 at 20:15 -0400, Alex Goncharov wrote:
| > 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 th
,--- You/Florian (Fri, 7 Oct 2011 03:21:23 +0200) *
| Sure. Deducing nullability isn't a hard problem, at least not if it's
| OK to simply say "nullable" if things get too complex.
Yes.
| > And in PostgreSQL, this could be done by combining
| >
| > (1) Oid PQftable(const PGresult *res, in
,--- You/anara...@anarazel.de (Fri, 07 Oct 2011 02:54:39 +0200) *
|
| > Given a SELECT (or possibly, simpler, a table name), tell me which
| > columns are non-nullable?
| That doesnt explain why it's needed.
It's needed for some meta analysis. That's as much as I can say.
| To get communi
,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) *
| > a lot of cases where the database could deduce (quite easily) that a
| > result column cannot be null
| Could you quickly explain what exactly you want that information for? Just
| because it has been done before doesn't necessarily mean
The obvious typos (sorry if this is a duplicate message, I sent the
first one from a wrong address):
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2, if I didn't see th
,--- 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:
|
|
,--- You/Florian (Fri, 7 Oct 2011 01:00:40 +0200) *
| On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
| > ,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
| > | Sure, but there are still a lot of cases where the database could deduce
| > | (quite easily) that a result column
,--- 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.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
,--- I/Alex (Thu, 06 Oct 2011 16:22:28 -0400) *
| Th
,--- 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.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
This function is not about the nullability of a column
My understanding is that libpq does not allow one to find if a result
set column is nullable.
Is this right?
(I know how to get a table column nullability information from
pg_attribute.attnotnull, but when coding around the libpq API:
* Is, OMG, ugly.
* Doesn't cover the arbitrary SELECT st
,--- Abhijit Menon-Sen (Tue, 25 May 2010 17:26:18 +0530) *
| Unless you explicitly declare and fetch from an SQL-level cursor, your
| many GBs of data are going to be transmitted to libpq, which will eat
| lots of memory. (The wire protocol does have something like cursors,
| but libpq does not
,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) *
| No equivalent of FETCH_COUNT is available at the libpq level, so I
| assume that the interface I am using is smart enough not to send
| gigabytes of data to FE.
|
| Where does the result set (GBs of data) reside after I call
| PQexecPrepared?
I have some libpq-using application code, in which fetching the data
follows this logic (after a statement has been prepared):
PQexecPrepared(pg_result, pg_conn, pg_statement_name, input_param_cnt,
param_values, param_lengths, param_form
22 matches
Mail list logo
