FAQ
The documentation for PQexecPrepared says:

(There is not currently a provision to obtain different result
columns in different formats, although that is possible in the
underlying protocol.)

Would anyone be interested in a patch to allow this?

I could, for example, change PQsendQueryGuts to do something like:

static int PQsendQueryGuts( PGconn *conn,
const char *command,
const char *stmtName,
int nParams,
const Oid *paramTypes,
const char *const *paramValues,
const int *paramLengths,
const int *paramFormats,
int resultFormat,
... ) /* Add this last argument. */
{
...

if ( resultFormat == -1 ) { /* or == nParams, perhaps? */
va_list args;
const int *resultFormats;

va_start( args, resultFormat );
resultFormats = va_arg( args, const int * );
va_end( args );

if ( pqPutInt( nParams, 2, conn ) < 0 )
goto sendFailed;
for ( i = 0; i < nParams; i++ )
if ( pqPutInt( resultFormats[i], 2, conn ) < 0 )
goto sendFailed;
}
/* This is what libpq does already. */
else if ( pqPutInt( 1, 2, conn ) < 0 ||
pqPutInt( resultFormat, 2, conn ) )
goto sendFailed;

...
}

And then teach the other API functions (PQexecParams, PQsendQueryParams,
PQsendQueryPrepared) to accept and pass on the extra ... argument. That
wouldn't break existing code, and new users could set resultFormat to
invoke the new behaviour. It seems a bit ugly, but on the other hand,
it doesn't seem worthwhile to add a new interface for this behaviour.

Thoughts?

-- ams

Search Discussions

  • Tom Lane at Jun 18, 2004 at 5:11 pm

    Abhijit Menon-Sen writes:
    The documentation for PQexecPrepared says:
    (There is not currently a provision to obtain different result
    columns in different formats, although that is possible in the
    underlying protocol.)
    Would anyone be interested in a patch to allow this?
    Yes, but not the way you suggest. The ... approach forces calling code
    to know *when it is written* how many result columns there will be,
    because you'd have to actually write that number of parameters in the
    call. This is true in some simple cases but it's way too inflexible.

    AFAICS this would need additional libpq functions with different
    signatures, viz a count+array of result formats. I desisted from doing
    that in the 7.4 cycle because I thought the whole PQexec API probably
    ought to be rethought in the light of the v3 protocol, and I didn't want
    to provide a plethora of functions that would soon be deprecated.

    No one's gotten around to thinking about a more general redesign of
    libpq's query API yet, but I'd rather see us do that than put more
    warts on the functions we have ...

    regards, tom lane
  • Abhijit Menon-Sen at Jun 18, 2004 at 10:20 pm

    At 2004-06-18 13:11:19 -0400, tgl@sss.pgh.pa.us wrote:
    Would anyone be interested in a patch to allow this?
    Yes, but not the way you suggest. The ... approach forces calling
    code to know *when it is written* how many result columns there will
    be, because you'd have to actually write that number of parameters in
    the call.
    I suspect I didn't explain my proposal sufficiently well.

    The signature of, say, PQexecParams does get ... added on to it, but new
    callers pass in only a count and an array, not one argument per expected
    result. That way, existing callers would continue to compile without any
    changes, and new code tells the function to look for the extra arguments
    by specifying a currently-invalid value for the resultFormat parameter.

    That said, however:
    No one's gotten around to thinking about a more general redesign of
    libpq's query API yet, but I'd rather see us do that than put more
    warts on the functions we have ...
    I am in complete agreement with that sentiment.

    -- ams

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 18, '04 at 3:06p
activeJun 18, '04 at 10:20p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Abhijit Menon-Sen: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2021 Grokbase