Michael Meskes wrote:
> On Mon, Nov 16, 1998 at 02:19:32PM -0600, Taral wrote:
> > separate stages. Are we also planning to support PREPARE? If so, we should
> > co-ordinate the effort, since the full COSQS support will require pulling
> > apart pg_parse_and_plan().
>
> Hopefully. I'm still holding back PREPARE for ecpg until I can think of a
> good solution. The best of course would be in the backend. Hmm, how do ODBC
> and JDBC solve this?
Speaking for ODBC, we keep the PREPARE'd statement in a malloc'ed buffer in the
driver. The fun part is that we must support a set of API calls which request
things like the number of parameters, and result set, column info. We get the
parameter count by simply counting the parameter markers. To get the column
info, we send the statement to the backend, retrieve the column info and discard
any returned rows. Not very elegant nor inefficient. But it works ok.
This functionality should be handled by the backend. May I suggest a protocol
that will allow this typical interchange.
send PREPARE(statement)
receive stmt_handle
send GET_PARAM_COUNT(stmt_handle)
receive param_count
for i = 1 to param_count send DESCRIBE_PARAMETER(stmt_handle, i); -- include: type, nullability,
scale, & precision receive parameter description.
end for
send GET_COLUMN_COUNT(stmt_handle);
receive column_count
for i = 1 to column_count send DESCRIBE_COLUMN(stmt_handle, i); -- included: tablename,
column name, column alias, type, nullability, scale & precision receive column description.
end for
-- There are other column info attributes worth sending such as: owner,
searchable, signed/unsigned, updateable, case sensitive & autoincrement
-- I will be quite content if we get the main ones specified above.
for n set of parameters for i = 1 to param_count send PUT_DATA(stmt_handle, i, param_data[i]) end for send
EXECUTE(stmt_handle) receive result set
end for
send FREE(stmt_handle)