Skip site navigation (1) Skip section navigation (2)

Re: libpq and prepared statements progress for 8.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Abhijit Menon-Sen <ams(at)oryx(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq and prepared statements progress for 8.0
Date: 2004-09-20 17:24:47
Message-ID: 12761.1095701087@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackerspgsql-patches
Abhijit Menon-Sen <ams(at)oryx(dot)com> writes:
> At 2004-09-20 11:02:50 -0400, tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
>> (2) What about discovering the actually resolved parameter types?

> Do you have any suggestions?

It depends on whether you think that PQprepare should bundle the
Describe Statement operation or not.  You can make a good argument
either way: (a) for apps or drivers that don't need to find out the
actual arg types, bundling in the Describe would be a waste of cycles;
but (b) if you need the Describe then it's a loss to have to spend an
extra network round trip to get the results.  Neither of these overheads
is compellingly large, though.

If you want it unbundled then a separate function is easy enough,
perhaps
	PGresult * PQdescribeStatement(PGconn *conn,
				       const char *stmtName,
				       int *numParams,
				       Oid **paramTypes);
where *paramTypes receives a pointer to a malloc'd array (caller
to free after use); or null on failure.  The PGresult would just
be used to convey success/failure.

If you want it bundled, perhaps add output parameters defined
similarly to the above to PQprepare.

It'd be possible to handle both cases in PQprepare: add the out
parameters, but say that passing NULL for them indicates the Describe
step is not wanted.  I dunno if that's too complicated.

You had mentioned wanting to support async operation.  We couldn't very
reasonably support async operation with separate output parameters ---
it would be a lot cleaner if the param type list were embedded in the
PGresult instead, so that PQgetResult would be sufficient.  I understand
your distaste for multiplexing the use of the PGresult fields, but still
I think it would be most sensible to define PQnfields() and PQftype()
as the way to extract the information from the PGresult if we go that
way.  We could invent a new PQresultStatus, say PGRES_PREPARE_OK,
as a way to distinguish a PGresult of this kind from the normal
query-result object.

If you prefer this last case then I think the cleanest approach is just
to automatically bundle the Describe operation into PQprepare.  You
could imagine adding a boolean to PQprepare's param list to specify
whether you care about getting valid parameter type info back or not,
but I think that looks way too much like a wart.

If you need more options, I can probably think of some ;-)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-09-20 17:29:01
Subject: Re: No parameters support in "create user"?
Previous:From: AndreDate: 2004-09-20 17:08:39
Subject: Re: schema level variables and deferrable unique constraints

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-09-20 17:35:56
Subject: Re: French translation updates for 7.4 and 7.5
Previous:From: Tom LaneDate: 2004-09-20 17:05:40
Subject: Re: libpq and prepared statements progress for 8.0

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group