Re: Native OLE DB. What do you think about it - Mailing list pgsql-hackers

From Marek Mosiewicz
Subject Re: Native OLE DB. What do you think about it
Date
Msg-id 003c01c21613$ceef63a0$206516ac@2210446
Whole thread Raw
In response to Re: [ODBC] KSQO parameter  ("Dave Page" <dpage@vale-housing.co.uk>)
List pgsql-hackers
> "Marek Mosiewicz" <marekmosiewicz@poczta.onet.pl> writes:
> > 1.is it safe to use binary cursors (basic types format e.g date would
not
> > change in future)
>
> Don't do it.  The internal representations are NOT guaranteed stable,
> and moreover any such thing will guarantee that your code can not talk
> to servers running on non-Intel architectures.  (I'm sure MS/Intel
> would love you to do that, but don't.)
So I will not.

But any way is it difficult to froze basic types. I believe that producing
and parsing data takes some time both on server and client. Acctually it is
question about prepared statements, but I think it is not pay off. It can
take some time to parse parameters if you have many same queries updates
(very common situation e.g. sending back  inserts/ updates from client).
you could then :
 'Qselect * from a where a=? and b=?P<binary parameters>
<return binary result>
update a set x=? where y=?P<array of parameters - make the same query nth
times with different values>

Such prepared statments would not only benefit from cached plan but also
avoidance of parameter parsing and sending it - multiple times across
network -.

Most DB intefaces has some support for such batch execution so it could be
used (OLE DB JDBC) in it and gain speed)
It could be easy do decide to use exclusive little or big indian - such
conversion is many times faster than atoi(). I don't know if it is problem
to froze binary representaion of data but if it is not frozen then you could
never use bianry cursor from client).

I have no idea how diffcult it would be to implement so I don't know if it
it has sense, but it is only my propostion.
>
> > 2.how could I control result type (binary/ASCII) for ordinary SELECTS ?
>
> You can't, but it doesn't matter, see above.
>
> regards, tom lane




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Massive regression failures
Next
From: Bruce Momjian
Date:
Subject: Re: Massive regression failures