Sławomir Cygan wrote:
> Hi,
> This is the actual status of the project:
>
> -ResultSets are implemented and working (uh. mostly).
>
> -Up to 8.1 all test are passing, i'm doing fixes now, so I expect more
> will be passed today.
>
> -driver recognizes only "varchar" type: Implemementing types would be
> done by small trick:
> As libpq expect types have to be precized in PQprepare() call,
> ResultSet constuctor will check if any types were set (changed from
> varchar) after "::db prepare". If yes, new postgres statement will be
> prepared (another PQprepare call), similarly to the scenario, when
> STMT_FLAG_BUSY flag is set. By doing this sql statement will be parsed
> during "db prepare", and also type's oids will be set properly.
>
This is great news! I've been out of town for the last couple of days,
so I haven't been able to continue my efforts at tracking down
memory management issues. Maybe by now you've fixed them.
I'm not sure that we need to be so very specific about the types.
When I set up the initial type system, I had two major concerns,
plus a minor one.
(1) SQL's syntax for numbers is somewhat different from Tcl's,
so it's important to use Tcl's format conversions for things
that we know are numeric. For that reason, the various types
of Booleans, integers and floating point numbers were converted.
(2) Many SQL APIs do strange things for types like BINARY and BLOB,
where the data are a byte array rather than a character string.
Rather than trying always to adapt to the way a database handles
binary data in string form, the TDBC API allows the binary type
to be set on a query as well.
(3) A minor consideration: Using Tcl's cached internal representations
where they exist saves a little bit of time.
So it's not obvious to me that we have to follow changes to the
user-defined types at all. Couldn't we simply adopt the rule that
any type not in our predefined set is sent to the database engine
as a string and converted there? Am I missing something important?
--
73 de ke9tv/2, Kevin
|
