On 7 Feb 2002, Hannu Krosing wrote:
> But I guess that you can't fake PREPARE/EXECUTE on client side anymore
> if you want to be DRDA compatible?
DRDA has a facility for preparing and executing, but also for direct
execution. So, a server implementation would have to support all of the
AR Level 1 capabilities to be compatible. The client is a bit free-er to
choose how to send it's SQL. That is, the client has the option to fake a
prepare/execute but the server must service either method.
> Does DRDA have standard representation of datatypes on wire ?
DRDA has a quite extensive list of datatype representations. The ordering
of bytes is server dictated (as opposed to TDS where it is client
dictated, so server does the byte swapping if necessary).
> If so, how will postgres extendable datatypes fit in there ?
>
> I know that postgres's system tables have two sets of type i/o functions
> typinput | regproc |
> typoutput | regproc |
> typreceive | regproc |
> typsend | regproc |
>
> which are currently initialised to the same real functions
>
> hannu=# select count(*) from pg_type where typoutput <> typsend or
> typinput <> typreceive;
> count
> -------
> 0
> (1 row)
The server has the leeway to determine the DRDA representation for it's
dataytpes, and it is the clients responsibility to deal with it.
> I suspect thet the typreceive and typsend were planned for some common
> network representation, but such usage has probaly gone untested for a
> very long time.
good question.
Brian
