Обсуждение: specifying multiple result format codes with libpq

The documentation for PQexecPrepared says:
   (There is not currently a provision to obtain different result   columns in different formats, although that is
possiblein 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,
constchar *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

Abhijit Menon-Sen <ams@wiw.org> 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

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